Node.js 12 SemVer Major Cut-off

[BethGriggs]

/cc @nodejs/tsc @nodejs/release

Refs: nodejs/Release#417

PSA: SemVer Major Cut-off for Node.js 12 is 23rd March. After this time landing SemVer Major changes in v12.x will require no objections from the TSC.

(This issue will be closed after 23rd March - it was opened as an easy way to publicise.)

[Trott]

After this time landing SemVer Major changes in v12.x will require no objections from the TSC.

Feel free to ignore this question as a low-value can of worms that you would like to not open, but if you're into worms like I am:

Should that be the Release WG rather than TSC? Or is Release WG saying "TSC approval is the process for post-cutoff semver majors in this release"? Or something else?

I'm asking because, if I'm not mistaken, TSC delegated release contents to the Release WG in the Release WG charter. Only way TSC can have a say is if they revoke the charter or if the Release WG grants it to them.

[mcollina]

If I recall correctly, lwe have landed semver-major commits with TSC approval in this phase for the last few releases.

cc @jasnell

[jasnell]

@mcollina and @BethGriggs are correct, after the cut off it's always been semver-major only with no objections from TSC. The release wg can certainly weigh in on the discussion, as can anyone else.

@targos ... Where are things at with regard to v8 updates and necessary abi stability patches?

[targos]

@jasnell
The V8 version that we would like to have in Node.js 12 is 7.4.
PR: #26685
The PR includes what's needed to make it ABI compatible with 7.5 (@addaleax can you confirm?).
We have issues building on macOS (only in CI apparently, I think @ryzokuken could build locally) and AIX.

[addaleax]

The PR includes what's needed to make it ABI compatible with 7.5 (@addaleax can you confirm?).

It provides ABI compatible with V8 lkgr at the time of those patches – that goes further than V8 7.5, and we would need to re-float some of the patches after upgrading to V8 7.5 to keep ABI compatibility, with the goal of possibly enabling another V8 bump. If we decide to stick with V8 7.5, we can probably omit a number of patches.

[richardlau]

The plan was to stop at V8 7.6: #25082

[Trott]

@mcollina and @BethGriggs are correct, after the cut off it's always been semver-major only with no objections from TSC. The release wg can certainly weigh in on the discussion, as can anyone else.

Can of worms opened!

This practice, however long-standing, contradicts the Release WG charter which says the Release WG, not the TSC, has final authority over what goes in a release. (The TSC determines what goes in the master branch.)

As it says in the TSC repo material about working groups:

Once formed the work defined in the Working Group charter is the responsibility of the WG rather than the TSC.

So, TSC does not have authority over what ends up in a release. Release WG does. Which is why I asked:

Or is Release WG saying "TSC approval is the process for post-cutoff semver majors in this release"?

That's probably the easiest solution to aligning what's actually happening with the designation of responsibilities in the WG charter.

[ofrobots]

This discussion is infact about what goes into the master branch. Ultimately this flows into the 12 release, hence the confusion in terminology. My take is that tsc decision applies until the release wg actively working on release content.

…

On Thu, Mar 21, 2019, 4:53 PM Rich Trott ***@***.***> wrote: @mcollina <https://github.com/mcollina> and @BethGriggs <https://github.com/BethGriggs> are correct, after the cut off it's always been semver-major only with no objections from TSC. The release wg can certainly weigh in on the discussion, as can anyone else. Can of worms opened! This practice, however long-standing, contradicts the Release WG charter which says the Release WG, not the TSC, has final authority over what goes in a release. (The TSC determines what goes in the master branch.) As it says in the TSC repo material about working groups <https://github.com/nodejs/TSC/blob/a1f4f6fd6fc259996320fee10080d504df82f275/WORKING_GROUPS.md#nodejs-core-working-groups> : Once formed the work defined in the Working Group charter is the responsibility of the WG rather than the TSC. So, TSC does not have authority over what ends up in a release. Release WG does. Which is why I asked: Or is Release WG saying "TSC approval is the process for post-cutoff semver majors in this release"? That's probably the easiest solution to aligning what's actually happening with the designation of responsibilities in the WG charter. — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#26844 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAE0qYjNsAmFJxjAqCUaZTdeBoAL8oYWks5vZBuSgaJpZM4cCCAG> .

[refack]

We have issues building on macOS (only in CI apparently, I think @ryzokuken could build locally) and AIX.

Seems like it builds with XCode9 on macOS 10.12
https://ci.nodejs.org/job/temp-node-test-commit-osx/1/nodes=osx1012/ (just 1 failing test)

[Trott]

This discussion is in fact about what goes into the master branch.

@ofrobots Maybe I'm misunderstanding you, but it seems to me that it's pretty definitely about what goes in the release branch, not master:

...landing SemVer Major changes in v12.x will require no objections from the TSC.

That says that after the cut-off date, TSC can block semver majors from landing in the release branch, even though they've landed in master. But only the Release WG can decide what does and doesn't land in 12.x. (If they're voluntarily deferring to the TSC, cool. But there's no need for that and it would have to be something the Release WG as a whole decided.)

[Trott]

I'll stop now before I burn bridges that can't be rebuilt. I'm sure at least some people are beyond exasperated with me at this point on this topic.

This all does bring up one important issues for consideration elsewhere: The project as a whole often engages in practices that diverge from documented policies. We should not do that. Policies and practices should be updated to align.

And now I'll do this...

[gireeshpunathil]

I agree with @Trott :

• documented policies MUST be followed
• if policies are found to be stale / needing update, we can amend those, but through formal process

So in this context, it should be release WG's discretion to define the content, between the cutoff date and the actual release - I think this discretion should also be a major role of that working group .

However, if the matter at hand has implications that cannot be evaluated fully within the release WG's capacity, they can always ask for advise from TSC? (but should be fully at their discretion)

[richardlau]

This is the first major release of Node.js post-convergence that isn't being done by James. As such we are making an effort to document the steps so it can be repeated, and this is currently being PR'ed over in #25497 and would probably be a better place for discussing given that in its current state it is proposing:

One month or less before the release date, commits must be cherry-picked in to
the two branches. To land SEMVER-MAJOR at this time requires no objections
from the TSC.

[Trott]

On a totally different note: OMG, thanks for all the hard Release work! The activities of Release WG (and Build WG for that matter) can't be appreciated enough and it's not my intention to make things more work than they already are. (But since that's the likely short-term effect, it's another reason for me to stop already.)