Coinciding LTS and Current releases on the same day

[ofrobots]

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.

[MylesBorins]

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]

I like option A.

[ofrobots]

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]

Oh, there is no reason the releases have to be on the same day with either of those options.

[MylesBorins]

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]

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?

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.

a) making the initial LTS release include ONLY the changes to move the release line to lts

I think we should definitely do this.

[mhdawson]

Agreed to:

a) making the initial LTS release include ONLY the changes to move the release line to lts

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]

By people are we talking about release team members?

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.

making the initial LTS release include ONLY the changes to move the release line to lts

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.0 release several weeks before would have given us a venue to bake fixes.

We frequently have 3 security releases going out at the same time, so it's not exactly unusual.

Security fixes usually have a small number (usually 1) of patches. 9.0.0 and 8.9.0 were 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]

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]

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]

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]

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]

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?