A more public release date selection process for major releases

[isaacs]

Problem

While the general timing of major Node.js releases is fairly well established (October and April), the specific release date is typically set a month or so in advance. (In the case of Node v10, the specific date of release was proposed on Jan 15, but formally decided on March 2.)

Many of us in the community who need to time things around major Node.js releases for publicity purposes can't keep up with the multitude of nodejs/node issues (or, even, the discussions on this repo!) This is clear from npm getting caught off-guard (thinking the release was April 30), and some confusion on the part of the v8 team in this issue, just 2 weeks ago.

The release schedule and ics feed still do not have April 24 called out as the release date. However, it has been publicly announced and is right around the corner, so pushing it back to April 30 is not possible.

Proposal

I suggest the following process to help make this more smooth for all of us:

1. 30-60 days before cutting a new major release train, a specific date is picked, and a new issue created in this repo, with a title like v11.0.0 release date.
2. This date is added to the release calendar (the README.md of this repo), marked as TENTATIVE, with a link to the discussion issue. For two weeks, anyone can discuss pushing this date forward or back, and it's not "official" until the provisional period is over.
3. 2 weeks after the release date is picked, the provisional period ends. The TENTATIVE flag is removed from the date in the release calendar. (Of course, dates can still slip for significant technical reasons, or via a vote from the TSC.)

This has the following benefits:

1. Non-technical stakeholders can have a single page to watch to get a link to the "best guess" of a release date, and then determine whether that's final or still up for discussion (and even weigh in with considerations).
2. Fewer surprises about exactly when a release will be cut (iow, @jasnell doesn't have to answer the same question repeatedly ;)
3. Better alignment of Node.js, npm, and v8 releases and PR announcements, which helps all three projects.
4. Doesn't require much added work for anyone involved. (It's a few extra steps for @jasnell, but per number 2 in this list, maybe it balances out?)

[jasnell]

As the person who has cut every major release since 4.0.0, I'm completely on board with this. With each release I have been attempting to hone the process more and more with getting notifications out but with the volume of activity it's easy to miss those. Having a more formal process around a tentative date and a finalization of no more than 2 weeks later is definitely workable.

I would also add this: with every release there have been questions about "Can we slip this back a week to account for XYZ other thing" and I really want to get out of that cycle. Once a date is picked it needs to be firm so that everyone can count on it. The only thing that should be allowed to cause a ship date to slip are critical issues that need to be resolved. I think having better visibility around that the selection of the release date would go a long way towards ensuring this.

Thank you for the feedback @isaacs :-)

[jasnell]

(And I would go with a 60 day lead time... 30 days is way too short)

[cowperthwait]

At risk of launching a meta-bikeshed, I’d diverge from @isaacs only in what gets the emphasis.

Compare
“A more public release date selection process for major releases”
vs
“A more public release date selection process for major releases”

…you dig?

I don’t envy being on the receiving end of as many “Can we slip this back a week for XYZ” requests as I’m sure @jasnell must be; as the guy who marshals notifying the 9.x million npm users about new updates, I just benefit from advance warning about when I need to do it.

If not for an offhand comment from Zibby, our PR folks would still be kicked back for like another week before even starting to do briefings on this stuff. Learning of the 24th ship date was better than coffee for waking me up last week.

[cowperthwait]

( ⬆ npm’s head of marketing: long-time lurker, first-time commenter. Hi, hello.)

[cowperthwait]

60 day lead time... 30 days is way too short

ilu James

[MylesBorins]

Could it be as simple as "always the third Tuesday"?

…

On Wed, Apr 18, 2018, 8:18 PM Jonathan E Cowperthwait < ***@***.***> wrote: 60 day lead time... 30 days is way too short ilu James — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#325 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecVz-8xGN5rZKK26_VDKKWzOFGu7Nvks5tp9fdgaJpZM4Ta8r4> .

[jasnell]

@MylesBorins ... I'd prefer that, yes, but it's not always practical, especially for April given the way the Easter holiday likes to jump around. The "3rd Tuesday in April" in 2019 falls on April 16th, six days before Easter Sunday and in the middle of spring break. It generally would not be a great week for a major release. I think it would be better to say something like "The second to last Tuesday of the month is the ideal target" then select a specific date from there following the process @isaacs suggests.

[jasnell]

There's another aspect of this to consider: the proposed dates need to also include the proposed date for semver-major cut off. Invariably (even this week) I get lots of "well this semver-major is special and really should go in" and it would be fantastic to have that locked down more and much more visible.

Tho I will say that this time around has been a lot better than previous major releases, of which I am deeply thankful :-)

[mhdawson]

I'm +1 on documenting the process. It does need to have some flexibility in case there are critical issues as James mentioned.

[bnb]

Also +1 to documenting this process further. Both in terms of personal communication and corporate work, having the release dates being fuzzy has been... difficult.

Having a well-documented guide will also help ecosystem tooling build out their own release guidelines and processes. In talking with @TheLarkInn about our releases recently, I realized just how much tribal knowledge everyone working on Node.js (and commenting in this thread so far has), and how little of it we've made easily accessible to the outside world 😅

[isaacs]

@jasnell Good to know you're more in favor of a 60-day lead time. That's way better in my opinion, but I didn't wanna ask for more than I thought I could get :)

So, it sounds like the summary of the process for major releases is:

1. At ${release date - ~60 days}, a release date is selected, and announced as a provisional release target date, added to ics feed and readme in nodejs/Release. Issue is opened and linked from calendar, readme, tweets, etc.
2. For two weeks after provisional announcement, changes can be discussed and concerns raised. (Nudge a week here or there to align with or avoid conflicting with some big tech event, etc.) However, the LTS calendar month should still be accurate, so there isn't infinite flexibility, and if there isn't consensus, ultimate authority rests with the release manager to decide. (Ie, @jasnell currently)
3. After 2 weeks (${release date - ~46 days}), the date is finalized, along with cut-offs for PRs etc, and can only be changed via a TSC vote, or technical issues which cause a slip. Close issue (lock if necessary), mark date as official, update readme, calendar, alert the media/partners/projects/etc.

Where should this be documented? Can I send a PR to update the readme, or some other doc in this repo?

[MylesBorins]

@isaacs it seems like this should be documented in https://github.com/nodejs/Release#release-plan

PR sounds like a good place to reach consensus on this.

[MylesBorins]

I'm going to go ahead and close this, as I think this has been fixed. Please lmk if you need me to reopen it