Release a v5.2.1?

[ljharb]

v5.2.0 has a breaking repl bug (#4257). It was fixed in #4215 with a two-line change.

Could this be merged into the 5.2.x line and released as v5.2.1, so that the 5.2.x line no longer has breaking changes that would make it deserve to be a 6.x release? Hopefully git cherry-pick 1999fdc859ec80740f64e3af1dea54acbc4d4f37 plus the release process is not a burdensome amount of work for anybody.

[Fishrock123]

cc @nodejs/release

[silverwind]

5.3.0 just got released, that should solve it.

I think we need to be a bit more agile regarding emergency releases like in this case. Having a broken REPL for over a week with a fix already in master is not ideal. Adding CTC-Agenda.

[ljharb]

@silverwind that does not solve it, because 5.2.x still has a breaking change. Please reopen this?

[ljharb]

More specifically, if 5.2.x introduces a breaking change, then node isn't being a good semver citizen.

[silverwind]

I might be wrong, but I don't think we're providing any kind of LTS for minor versions like 5.2.x yet. Ideally, 5.2.1 should've happened right after the fix got commited. From what I gather, 5.3.0 is the 'fix' now that it is released.

[Fishrock123]

I think we need to be a bit more agile regarding emergency releases like in this case. Having a broken REPL for over a week with a fix already in master is not ideal. Adding CTC-Agenda.

I think having more releasers here would probably help. Sometimes myself, Rod, and James get tied up in other things (like Node.js Interactive!).

[evanlucas]

I would definitely be interested in helping out with releases

[MylesBorins]

I would be interested in helping with release as well

[ofrobots]

If a 5.2.1 does occur, it would need #4298 as well.

[rvagg]

My concerns about a 5.2.1 at this stage are:

1. the precedent that a 5.2.1 release would set and expectations users might have on how we support semver-minors and the nature of the Stable release line
2. the confusion it'd cause wrt our recommendations about what you should be using if you're using Stable.

Basically I think that Stable shouldn't be going backward, only forward. If you're stuck on 5.2.x and are reluctant to upgrade to 5.3.0 then it suggests you should probably be using LTS because your ability to handle change is too low for the pace that Stable is setting.

[jasnell]

+1 to @rvagg's comments.
On Dec 16, 2015 6:33 PM, "Rod Vagg" notifications@github.com wrote:

My concerns about a 5.2.1 at this stage are:

1. the precedent that a 5.2.1 release would set and expectations users
   might have on how we support semver-minors and the nature of the Stable
   release line
2. the confusion it'd cause wrt our recommendations about what you
   should be using if you're using Stable.

Basically I think that Stable shouldn't be going backward, only forward.
If you're stuck on 5.2.x and are reluctant to upgrade to 5.3.0 then it
suggests you should probably be using LTS because your ability to handle
change is too low for the pace that Stable is setting.

—
Reply to this email directly or view it on GitHub
#4316 (comment).

[cjihrig]

I'm also +1 to @rvagg's comments.

[silverwind]

My thoughts exactly @rvagg.

[ljharb]

I think that while LTS is a guarantee, all minor versions should be treated the same, LTS or not, unless there's a compelling reason not to backport a fix. Releasing a v5.2.1 isn't a recommendation at all that someone shouldn't upgrade to 5.3.0, it's a signal that unintentional breaking changes in a minor or patch will be reverted in that minor line, which should reassure users in the case of a future unintentional breaking change.

[jbergstroem]

If 5.3.0 wasn't out, I'd consider 5.2.1 being ok. Sitting where we are at the moment we've released a new – semver-minor – compatible version that fixes said bug.

[ljharb]

If you weren't planning on releasing a 5.2.1 after a 5.3.0, then I'd say 5.3.0 never should have been released until a 5.2.1 was released.

[silverwind]

I don't think there's anything more to be done here. Yes, the release should've happened sooner, but the release team are just humans who tend to get busy from time to time. #4319 is set out to hopefully improve this situation.

[ljharb]

Then I guess, please ensure that new minors are as delayed as long as possible to allow for patch fixes to the latest minor, since non-latest minors aren't going to get fixes.

[Fishrock123]

Then I guess, please ensure that new minors are as delayed as long as possible to allow for patch fixes to the latest minor, (...)

That's still not how this works. :/

It's a train, whatever comes in at each (weekly-ish) station that isn't breaking (as far as we can tell, and we do try pretty hard to ensure this) goes.

[Fishrock123]

From semver.org: (under the FAQ)

What do I do if I accidentally release a backwards incompatible change as a minor version?

As soon as you realize that you've broken the Semantic Versioning spec, fix the problem and release a new minor version that corrects the problem and restores backwards compatibility. Even under this circumstance, it is unacceptable to modify versioned releases. If it's appropriate, document the offending version and inform your users of the problem so that they are aware of the offending version.

I'm not really sure how we can document that other than updating the blog post.

Or, we could publish something like a list of DOA versions.

This still points to being what we did as OK even if a little slow.

The release was delayed by a combination of 3 things: Few releasers, weekends, and discovering a second regression, fixed later: #4298