Repository navigation
Coinciding LTS and Current releases on the same day #279
Description
Our policy states:
When a new odd-numbered major release is cut, the previous even-numbered major version transitions to the Long Term Support plan.
I would like to question why coinciding the two releases on the same day is necessary. Note that while the policy doesn't mention 'same day' explicitly, this is how we have chosen to interpret this statement in the project.
In practice this means that:
- The release team, the CI, and the project overall has to manage two releases concurrently. This puts extra burden on resources, processes, and most importantly, people.
- At the time the even-numbered branch is ready to transition to LTS, there is no Current stream. This means that any changes have be landed directly onto the to-be-LTS release (e.g. see [v8.x] https: revert "refactor to use http internals" node#16660). This means that we don't get the benefit of getting feedback from the ecosystem from the current branch, and potentially breaking changes can land into the LTS release.
I would like to propose that we try to separate the releases. It would have made sense to release 9.0.0 two weeks prior to 8.9.0 in the current example.
Activity
MylesBorins commentedon Nov 1, 2017
As it currently stands there is no way for us to do an "LTS" release when transitioning if the commits have not had an opportunity to bake in a Current release first.
As such this could likely be solved by either
a) making the initial LTS release include ONLY the changes to move the release line to lts
b) having the next major out a month in advance to allow for a proper baking pattern that we currently use for LTS
cjihrig commentedon Nov 1, 2017
I like option A.
ofrobots commentedon Nov 1, 2017
Option A doesn't address my first concern that doing two major releases on the same day is unnecessary burden on people and processes. Is there a rationale for why it has to be the same day?
cjihrig commentedon Nov 1, 2017
Oh, there is no reason the releases have to be on the same day with either of those options.
MylesBorins commentedon Nov 1, 2017
Having them on the same time simplifies UX for the website.
If we were to promote 9.x to Current before 8.x becomes LTS our current site would have 8.x vanish and 6.x still promoted
There is also a comms advantage to doing everything on the same day. It is a much stronger signal from a marketing and press perspective
I'm not saying this is a reason not to change things, more that the reason for doing on the same day is not non zero
gibfahn commentedon Nov 1, 2017
By people are we talking about release team members? I prefer having the releases on the same day, it makes things easier. Having two current releases going at the same time seems unnecessary to me. What burden are you talking about? We frequently have 3 security releases going out at the same time, so it's not exactly unusual.
I think we should definitely do this.
mhdawson commentedon Nov 2, 2017
Agreed to:
Otherwise I'll leave the rest of the discussion as to whether its a burden do both at the same time to those doing the releases.
ofrobots commentedon Nov 2, 2017
I think it goes a bit beyond that. As a collaborator, I noticed a lot of changes being rushed; the CI was over-subscribed and not quite healthy, and the resources to go figure out/fix the CI were scarce. Stuff I wanted to land took a significant amount of wasted time to land because of the churn. I am extrapolating from my experience.
The downside I see is that if we have otherwise reasonable changes ready to go, they will necessarily have to wait until the next LTS release. For example, if we have a fix baked, vetted, and ready to ship, it seems unnecessary to delay it to
8.9.1/8.10.0.Having had a
9.0.0release several weeks before would have given us a venue to bake fixes.Security fixes usually have a small number (usually 1) of patches.
9.0.0and8.9.0were substantial releases with a lot more change going on. Changes were getting added until at the last moment on the 9.0.0 branch. Did we do due diligence on all the changes that went in at the last moment? Personally, my attention was split between the two releases.schmod commentedon Nov 2, 2017
I just discussed something similar over in #281 and somehow missed this thread.
tl;dr; At the very minimum, I think that the first LTS release of a series should conform to the normal rules that we have in place for LTS releases (specifically, the 2-week probationary period during which new features need to live in Current, which means either a freeze 2 weeks before the first LTS, or cutting the new Current series a few weeks earlier)
richardlau commentedon Oct 9, 2018
As things stand the upcoming 11.0 release and 10 transition to LTS are not planned to happen on the same day.
Planned dates:
Tuesday 23rd October 2018 - 11.0 release #328
Tuesday 30th October 2018 - 10 LTS release #361 (comment)
which does mean for a week we will have two current releases.
targos commentedon Oct 9, 2018
If we do the next 10.x release tomorrow as planned, commits will have baked two weeks in a current release, so we would be able to transition to node 10 LTS on October 23
schmod commentedon Oct 9, 2018
That seems reasonable, as long as tomorrow's release is the final one under which 10.x is considered Current, and any (non-bugfix) changes in the subsequent 10.x release have spent at least 2 weeks baking in a 11.x release.
I'm not quite sure how this all shakes out from a development perspective -- do we start treating 10.x as though it's an LTS release from a development perspective starting tomorrow?
Having a week of simultaneous Current releases doesn't really affect much if there isn't a release during that week.
schmod commentedon Oct 30, 2018
I'm pretty happy with how this was handled for the 10.x LTS transition! 🎉
Does anything further need to be done or codified, or can we close this issue?
MylesBorins commentedon Oct 30, 2018
@schmod I think we could benefit from having a doc about planning new releases... is that something you would be interested in putting together?
MylesBorins commentedon Jan 7, 2019
Closing as we avoided this with the last release. Please reopen or ask me to if you think i've done so inappropriately