This repository was archived by the owner on Apr 18, 2018. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 18, 2018. It is now read-only.
Collecting LTS Requirements from the User Community #67
Description
This issue is a placeholder for discussion of LTS requirements from the broader user community.
- What is a reasonable LTS release schedule? (2 per year, 1 per year, 1 per month, etc)
- What is a reasonable LTS support timeframe (6 months, 1 year, 5 years, etc)
- What is a reasonable LTS maintenance policy (fixes only, etc)
- Is there anything in the proposed dev-policy that raises red flags as far as LTS support is concerned?
- What's missing / What haven't we thought about yet ?
Activity
shammond2000 commentedon Apr 29, 2015
@jasnell Might be good to understand the expectations on stability and backward compatibility. Similar for documenting the tests to be run before declaring the release is "ready."
aredridel commentedon May 1, 2015
I like what's written; it does leave a lot open for future definition, however.
point 3 above is the one that really needs clarifying. I'd love to see features brought into LTS releases, especially after being vetted in the mainline and the implications for the community more fully understood. Keeping API and maybe even ABI compatibility over LTS releases would be wonderful. These constraints work against each other, but I think might be the sweet spot for uses I see every day. Enterprise developers want the new shiny features, but at the end of the day, they need to be vetted a bit first.
totherik commentedon May 1, 2015
Thanks, @jasnell. As @aredridel mentioned, on our side we would like a cadence and maintenance policy that would allow us access to features. For us, the actual cadence is less important than having one in the first place. Observing that the release schedule of the main branch is expected to accelerate, the developer in me favors a schedule as frequent as quarterly releases, while the realist acknowledges twice per year would be sufficient and predictable for teams who are focused on delivering product.
I suppose it may be relevant to ask how many LTS releases we expect the LTS WG/community could/should support per the maintenance policy.
Also, does the LTS release also ship with npm, and if so, does the policy extend to cover npm fixes?
Fishrock123 commentedon May 1, 2015
I think it should. io.js 1.8.2 (maintenance) will definitely include an even newer npm.
mikeal commentedon May 1, 2015
Yup, but likely won't ever take npm 3.0 in a 1.x line because it's a breaking change release.
chrisdickinson commentedon May 1, 2015
@mikeal I wonder if we should "never say never" with regards to npm – I'm thinking about the problems caused by the introduction of
^in semver ranges, when old versions of npm didn't support the syntax.mikeal commentedon May 1, 2015
@chrisdickinson in that case we'd want to backport support for ^ to the prior npm release line rather than update an old node.js line to a breaking release of npm.
Fishrock123 commentedon May 1, 2015
That is definitely non-trivial as I recall from the node 0.8 situation and @isaacs' PRs to it.
mikeal commentedon May 2, 2015
From what I can remember the issue there was that node.js didn't want to update npm for any reason in an older release line. Supporting that new syntax would have been a feature addition, not a breaking change, and could have been done in an older line if that's what it would have taken for it to go in. Also, there has never really been a breaking changeset in npm the size of what is happening for 3.
jasnell commentedon May 18, 2015
Close in favor of moving discussion to LTS repo --> nodejs/Release#8