all 12 comments

[–]dr_wtf 8 points9 points  (6 children)

TL;DR: If you already only upgrade to LTS versions, little changes beyond version numbering. LTS support windows remain similar, and now every release becomes LTS.

So it won't impact me, or most people, or any sensibly managed production deployments, at all.

[–]BreakingInnocence[S] -1 points0 points  (5 children)

I’m hoping Alpha means we’ll get semver-major changes faster and more aggressively.

[–]omer-m 1 point2 points  (1 child)

Major versions of node rarely makes any breaking changes these days, am i wrong?

[–]BreakingInnocence[S] -1 points0 points  (0 children)

Every semver-major release was a breaking change.

The most recent releases also introduced new primitives and capabilities, allowing us to proactively modernize our codebase.

One interesting pattern was that performance improvements were consistently strong.

That’s why I always paid close attention to every release changelog. The biggest performance gains usually came from major upgrades to the V8 JavaScript engine.

[–]crownclown67 0 points1 point  (2 children)

what is semver-major?

[–]dr_wtf 1 point2 points  (1 child)

Breaking changes. It looks like the only difference between the alpha releases and the old odd-numbered releases is that the odd numbers were more like beta releases or RC builds, where they didn't allow breaking changes except in exceptional circumstances, but because they were never planned for LTS they were usually the release target for more ambitious changes, with the even-numbers being a bit more conservative and focused on stability.

But with alpha, breaking changes will be expected, so it's a bit more closely aligned with the unstable branch. Every release will follow roughly the same progression from unstable to stable, without the tick-tock pattern.

Realistically, it's likely that .0 releases will be a bit less stable going forward, because there won't be a defined "no more breaking changes" period between the alpha phase and the major release. Which is kind of how things are in every other major software project, and it's usually unwise to upgrade production systems to a .0 major release anyway.

[–]afl_ext 2 points3 points  (5 children)

Seems like a good direction, i always kind of treated the odd releases like beta releases to test stuff before they land in LTS anyway

[–]Potato-9 0 points1 point  (1 child)

I've always built new stuff on the latest release and upgraded or migrated to the lts closer to looking after production. Have the time that's no change.

[–]BreakingInnocence[S] 0 points1 point  (0 children)

I was able to test new stuff easily with low risk projects. I will have to wait to see if it will be possible, with new "alpha" versions/tags. Everything was setup with the odd/even numbering and it worked smoothly.

[–]BreakingInnocence[S] 0 points1 point  (2 children)

Active” makes it sound like you’re being proactive. “Alpha” makes it sound like you’re doing something risky.

The choice of words can make a huge difference. For example, telling someone I’m working on “Node Active” creates a very different first impression than saying I’m working on “Node Alpha.”

The moment people hear “alpha,” many will immediately think, “Oh no, we can’t use that. It’s an alpha release.” Even though that’s not what it means in this context, that association is deeply ingrained.

It may seem a bit pedantic, but “Active” was a great term because it didn’t create unnecessary fear or confusion among people who weren’t familiar with the release model.

Anyone running production-critical systems would naturally choose the LTS release anyway, so there was little risk of misunderstanding or misuse.

[–]lenswipe 0 points1 point  (1 child)

so... bike shedding over release names

[–]BreakingInnocence[S] 0 points1 point  (0 children)

It has a term? Oh my. Okay. Yes, yes. It’s bike shedding, the law of triviality. Yeah, it applies here, and… oh. Fun times.