request for clarification

[refack]

Triggered by a nodejs/node#12586 (comment)

AFAIK v4 is the first time a "major" release enters "maintenance". IMHO this is a very interesting point in time for the project, and deserves some explicit clarifications...

We should explicitly elaborate on some statements:

Once a release moves into Maintenance mode, only critical bugs, critical security fixes, and documentation updates will be permitted.

• What about auxiliary code like benchmark, test, and tools?
• Improvements in the build process?
• In general how much are we allowed to break compatibility in master?

The staging branch is used to land cherry-picked or backported commits from master that need to be included in a future release.

Does that mean all changes must come from master? What if we need to fix something that is exclusively v7 related? or in code that does not exist any more in master?

/cc @nodejs/lts @nodejs/ctc @nodejs/collaborators

[refack]

[personal opinion]

I'm sure it won't surprise you to know that I'm pro-break-everything 😈 (tough I try to be aware of the consequences, and always willing to deal with the fallback). But I do think it's super critical to have version lines that are stable and dependable. What I suggest is that we should reduce the impact of maintaining v4 on the development in master (re: nodejs/node#12586).

IMHO this is a watershed moment in the project, we can decide we are "unshackled" by v4 compatibility and start running for v9/vNEXT a.k.a master
As a long time developer (17 years) and nodejs user (7 years), I also passionately hate it when APIs break, but I'm afraid that this hate of breakage is hindering innovation in the master branch.

We should make a clear distinction between the work done toward all our competing efforts, i.e. "maintenance", "LTS", and "vNEXT". I believe it will require distribution of dev effort, but maybe the org is strong enough to achieve both goals in two branches (backwards stability, and forward innovation).

P.S. I'm volunteering to join the LTS group and help with backporting.

[jasnell]

The intent of Maintenance is to ensure that a particular major remains stable and does not change. It's not a invitation to make more change. This process was discussed at length in consultation with many users and I'm not particularly keen on changing it at this point.

[refack]

This process was discussed at length in consultation with many users and I'm not particularly keen on changing it at this point.

I assumed so, I wanted to know what were the decisions.

[refack]

P.S. When refering to change, I only mean in vNEXT.

[mikeal]

There's something sort of unsaid in all of this: maintaining multiple release lines is a burden.

It's impossible to maintain a line forever and the stages we have are the most responsible way we've found to give people ample time to upgrade even if they never take a CURRENT release and stick only to releases we consider stable.

Increasing the scope of changes to the releases in the maintenance line would increase the burden of maintenance. If you wanted to alter the criteria for changes in the lines you'd have to prove that it not only improved the release line but also that it does not increase the burden of maintenance.

Improvements in the build process?

This is an interesting question. If a build system change makes it easier to keep the line up to date then I could see a good argument for it. I recall this being one of the things that really plagued us with v0.10 and even v0.12.

[refack]

I want to make myself clear. I don't want to change the scope of either "maintenance" nor "LTS". I agree it is critical to have stable versions users can rely on.
_{My own personal opinion is that we should run faster in "latest"}

My main request is for elaboration on

Once a release moves into Maintenance mode, only critical bugs, critical security fixes, and documentation updates will be permitted.

If this excludes auxiliary code, are we allowed to break compatibility with v4 in test or benchmarks in the master branch (re nodejs/node#12586)?

There's something sort of unsaid in all of this: maintaining multiple release lines is a burden.

I am referring to that in my personal opinion. I totally agree! But there should be an explicit decision how much effort is given to each. Unfortunately IMHO giving 100% to either (maintenance or improvement) will be detrimental to the project.

[mikeal]

If this excludes auxiliary code, are we allowed to break compatibility with v4 in test or benchmarks?

We don't really think about breaking changes in this way. Breaking changes are allowed to land between major releases. Breaking compat between LATEST and v4 and LATEST and the prior major releases are basically the same thing. The only exception would be if the code diff was massive enough to introduce difficulties in merging things back to LTS, so if a large change (not just an addition) caused a lot of churn for not much benefit then it would probably not be accepted.

I think we're starting to mix up "large code changes" with "breaking changes." Many breaking changes are relatively small code changes. Large code changes that can potentially cause a lot of churn and give us a lot of maintenance burden so that burden is weighed against the real value of the code change. Auxiliary code is almost never exposed to the public API and so there are rarely what we would consider "breaking changes" but there are "large code changes" considered occasionally.

The primary consideration in every breaking change is how it effects the ecosystem. There are other considerations, but that's the primary one. It turns out to be quite difficult to quantify what impact some changes have on the ecosystem, that's why we have CITGM and why we occasionally pull back breaking changes in LATEST after they show to have larger negative impact than originally intended.

It's tempting to write a policy that stages breaking changes in such a way that anything can be changed but, in my experience, it just doesn't work. We're at the mercy of our ecosystem. Far more people value their code not breaking than any group of people want a change or feature. In fact, the history of Node.js is a history in which we are forced to stabilize before we want to as a response to rapid adoption.

[refack]

@mikeal thank you for the informative answer.
As an experienced dev and IT manager, I think I can understand the concerns you are referring to and IMHO the LTS schedule is a very good solution as it provides decision makers a guarantee about the future of the platform.

I have two other followups:

1. Remove indexOf usage from tests in favor of includes node#12586 - an example of whether we should invest in the future (maintainability/readability) vs. minimize dev burden when backporting. So do we improve our code, or keep it stable for easy backporting?

2. I'm predicting the next big pushback will be "why aren't you innovating?", and that it's already starting. IMHO we should take those voices into consideration as well. I posit that in v9 should prioritize innovation, since that's what odd-versioned versions are for. And in parallel, as you said, be prepared to give the managed backporting process the dev resources it deserves (i.e. not leave @MylesBorins to do it all alone 😉 [I'm exaggerating, and mean no disrespect to anyone!])

[refack]

Another question (I'm just asking since I was not part of the process, and want clarity):

The staging branch is used to land cherry-picked or backported commits from master that need to be included in a future release.

Does that mean all changes must come from master? what if we need to fix something that is totally v7 related? (re nodejs/node#12364)

[refack]

@kgryte, might have too been harsh, sorry. Edited.

[jasnell]

Yes, generally all changes land in master first and are cherry picked back. Exceptions can be made on a case by case basis only with CTC approval. That would typically only be done for security issues, critical bugs, or fixes to code that no longer exists in master.

[refack]

@jasnell thank you for the answer 👍