You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The intention of this issue is to bike-shed the specifics of how we maintain a release. This could actually be quite simple but I want to make sure we think this through properly.
How do we name these things?
For the NodeSource Linux repositories for Node, I made the call that we should start splitting them up by name and branch. Both the setup scripts and repo directories have these names and the pattern we're using should work for io.js LTS releases (in fact I was imagining LTS at the time).
iojs_1.x - for all standard releases with 1 as the major version, it'll become deprecated at some point we we'll encourage everyone to move on but they'll have to opt-in like we're doing for Node.js 0.10 -> 0.12.
iojs_2.x - for the next series of standard releases with 2 as the major. You have to run a separate setup script and download from a separate repo to get these.
iojs_1.9.x (or perhaps with an -lts in there?) for LTS releases based on the 1.9.x series, again you have to opt-in to this repo to get them but once you're in all you get is 1.9.x.
i.e. I'm suggesting simply 1.9.x as how we label an LTS, possibly with an lts in there somewhere.
Do the files and directories just get named exactly as we're naming standard versions or do we put an lts in the name somewhere? iojs-v1.9.32-lts-linux-x64.tar.xz, does it matter?
Do we have anything in the executable that identifies it as an LTS? Perhaps something in process.versions?
Do we have a completely separate group of people that are authorized to cut an LTS release to standard releases?
My feeling is that the LTS WG would end up having its own, separate discussions, maybe even moving discussions from iojs/io.js to this repo in some cases, therefore people deeply involved in LTS should be responsible for cutting the releases because the field of responsibility is entirely different. But perhaps I'm over-thinking.
Anything else we need to discuss?
The text was updated successfully, but these errors were encountered:
The intention of this issue is to bike-shed the specifics of how we maintain a release. This could actually be quite simple but I want to make sure we think this through properly.
How do we name these things?
For the NodeSource Linux repositories for Node, I made the call that we should start splitting them up by name and branch. Both the setup scripts and repo directories have these names and the pattern we're using should work for io.js LTS releases (in fact I was imagining LTS at the time).
iojs_1.x
- for all standard releases with1
as the major version, it'll become deprecated at some point we we'll encourage everyone to move on but they'll have to opt-in like we're doing for Node.js 0.10 -> 0.12.iojs_2.x
- for the next series of standard releases with2
as the major. You have to run a separate setup script and download from a separate repo to get these.iojs_1.9.x
(or perhaps with an-lts
in there?) for LTS releases based on the1.9.x
series, again you have to opt-in to this repo to get them but once you're in all you get is1.9.x
.i.e. I'm suggesting simply
1.9.x
as how we label an LTS, possibly with anlts
in there somewhere.Where to we release to?
Do we just make a
1.9.x
branch under https://iojs.org/dist/ for a1.9.x
LTS branch?How do we label LTS releases?
lts
in the name somewhere?iojs-v1.9.32-lts-linux-x64.tar.xz
, does it matter?process.versions
?Do we have a completely separate group of people that are authorized to cut an LTS release to standard releases?
My feeling is that the LTS WG would end up having its own, separate discussions, maybe even moving discussions from iojs/io.js to this repo in some cases, therefore people deeply involved in LTS should be responsible for cutting the releases because the field of responsibility is entirely different. But perhaps I'm over-thinking.
Anything else we need to discuss?
The text was updated successfully, but these errors were encountered: