search

nodejs / snap

Node.js snap source and updater
MIT License
167 stars 38 forks source link

Should have a "LTS" channel and a "Stable" channel #14

Closed jehon closed 3 years ago

jehon commented 3 years ago

It should be interresing to have a "lts" and a "stable" channel, to match the classic release cycle and the "packages" release cycle.

No need to have exactly the same packages, but having something "similar" in both system would be a plus.

It already exists for the edge channel, matching the latest dev version (15 as of last checked).

So, this should be great:

name current target status alternative (1)
stable 16.* beta
lts 14.* stable
edge 15.* already exists edge

(1) these alternatives better match snapcraft documentation, but are less intuitive in this case.

Use case:

Those two channels should be "new" one, not confusing existing one. They should follow also the "official" releases...

rvagg commented 3 years ago

The reason we've gone with channels as they are now is because of the sharp breakage, particularly ABI but also API, between major versions of Node.js. We even worked with Snapcraft to make this model work well enough and be a standard way of doing Snaps as opposed to their usual "just stick it all in 'standard'".

Having an "lts" channel would suffer the same downsides, but even more pronounced. Consider that one day you'd be happily using Node.js 14.x which has been working for the past 12 months, then suddenly you wake up and nothing works anymore and all your addons need to be compiled and you're getting deprecation warnings on your console or maybe an API has completely disappeared, all because we shipped a 16.x to your previously stable "lts" channel and Snap installed it while you weren't watching (this could even happen in the middle of a dev session sue to the Snap upgrade cycle, not just overnight).

So the model we have is one where you opt into a major release line and it stays stable over its life. We put a lot of effort, since Node.js 4, of keeping major release lines stable and sticking to semver rules as strictly as possible, so this works fairly well for Snaps. It shouldn't matter if you get an upgrade from Node.js 14.1.0 to 14.2.0 in the middle of a dev session, the ideal is that you shouldn't even notice it.

"edge" is a special case where all bets are off, it could break from day to day, you're opting in to chaos and it's called "edge" for a reason.

jehon commented 3 years ago

Ok, that seem reasonable to me...

And reading what you wrote let me remind that nodejs releases are also made by major (thinking about the setup_x.sh scripts).

Fair enough.

Thanks for your (good) explanation. I hope this will stay for other to understand the release cycle :-).

I will close this now.