Repository navigation
request for clarification #203
Description
Activity
[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
v4on the development inmaster(re: nodejs/node#12586).IMHO this is a watershed moment in the project, we can decide we are "unshackled" by
v4compatibility and start running forv9/vNEXTa.k.amaster
As a long time developer (17 years) andnodejsuser (7 years), I also passionately hate it when APIs break, but I'm afraid that this hate of breakage is hindering innovation in themasterbranch.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.
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.
Reacted by Refael Ackermann, Mikeal Rogers, Rich Trott, Athan and Hutson BettsThis 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.
P.S. When refering to change, I only mean in
vNEXT.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.
Reacted by Jan Olaf MartinReacted by Refael AckermannI 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
v4intestorbenchmarksin themasterbranch (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.
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.
Reacted by Refael Ackermann, Athan and Hutson Betts@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:
-
Remove
indexOfusage from tests in favor ofincludesnode#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? -
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
v9should 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!])
Reacted by Athan-
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 totallyv7related? (re nodejs/node#12364)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.
Reacted by Refael AckermannFYI
0.10and0.12were both maintenance releases for a year.Closing as there does not appear to be anything left to discuss here. Can reopen if necessary.
Triggered by a nodejs/node#12586 (comment)
AFAIK
v4is 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:
benchmark,test, andtools?master?Does that mean all changes must come from
master? What if we need to fix something that is exclusivelyv7related? or in code that does not exist any more inmaster?/cc @nodejs/lts @nodejs/ctc @nodejs/collaborators