Node.js LTS Policy #1
Conversation
|
For awareness, /cc @thealphanerd |
|
thanks for pinging me @nathanhammond perhaps we can discuss on a future @nodejs/lts wg meeting I'll comment in line with thoughts |
|
|
||
| # Detailed design | ||
|
|
||
| The current major version of Yarn will work with any Node.js version which has ceased being supported within the last year. One year after the Node.js LTS Working Group's cease of support announcement for any particular major version Yarn will no longer explicitly support that version of Node.js. It will then remove that version from its automated tests. |
There was a problem hiding this comment.
Will this include current versions of Node that have dropped support? For example v7.x is being cut later this month. Support for it drops in April. Will yarn continue to support v7.x for an extra 8 months? The usage statistics that we saw had a pretty major drop off of v5.x when v6.x was cut
There was a problem hiding this comment.
Made concrete, if v7.X ceases receiving support on April 1, 2017 then this proposal states that all versions of Yarn released before April 1, 2018 should work in v7.X. On April 2, 2018 any new release (be it major, minor, or patch) may drop support for v7.X.
Usage statistics are almost an aside here, we have to decide how much we want to help the long tail move after their version of Node.js has ceased receiving support. It's possible that many packages in the ecosystem will require certain modern Yarn behavior which would instead make the upgrade process require multiple steps:
- Move to next Node.js version.
- Move to next Yarn version.
- Install, hopefully engine-strict has your back (likely not).
- Rinse, repeat.
From our experience in the Ember community it's incredibly difficult to install a working set of dependencies for an out-of-date version of Ember if we need to make a security patch. We've written tooling to help us get insight into how things have changed between dates. Adding more variables into that process will make it a miserable experience.
There was a problem hiding this comment.
One year after the Node.js LTS Working Group's cease of support announcement for any particular major version Yarn will no longer explicitly support that version of Node.js
Why should we support Node.js versions that Node themselves don't support? How much value is there in continuing to support EOL builds of Node?
There was a problem hiding this comment.
Doesn't that depend on what users choose to do? node's dropping 0.10 support this month, but if actual usage doesn't drop, then everyone else should still probably be supporting it.
There was a problem hiding this comment.
@Daniel15 Foundational tools in an ecosystem need forward and backward compatibility guarantees which are stronger than most projects. The package manager is the gateway to the ecosystem in a way that even Node.js isn't and in my estimation should help provide a bridge for late upgraders. @ljharb also makes a salient point: just because it is unsupported doesn't mean it is unused or was used to bundle an old package which needs a security update.
This exists as the current state of npm which dropped testing of 0.8 in only June of this year.
The costs to this (since Yarn already transpiles) are much smaller and generally limited to API surface area added to Node.js. Any of these changes which are truly required (by rule they won't be since it will have worked in those versions before they were deprecated) can have a module written for it to polyfill the functionality. Delaying adoption and writing node packages is even good Node.js community stewardship as it provides tools for community members to incrementally migrate to the future.
Ember's policy (disclosure: author) guarantees that the HEAD of the master branch works without transpilation until the day Node.js ceases support. This makes it easy for us to maintain support for already-released versions. These tradeoffs are not fun but are required to build trust within the community.
Note that I find it completely legitimate that Yarn never supports 0.10 or 0.12 as those were already closing in on EOL at launch.
|
|
||
| # Unresolved questions | ||
|
|
||
| How much appetite is there in to maintain this project in legacy versions of Node.js? |
There was a problem hiding this comment.
How will the LTS branch's of yarn be handled? Will there be an active + maintenance period for backporting?
|
Just heads up that we probably want to solve a lot of things in order around governance, release processes, etc. There's a lot going on right now having just released and being flooded with issues, so don't expect a ton of immediate movement on this for those reasons. |
|
@thejameskyle Yep yep, just opening this as Ember's resident LTS policy wonk (note the byline on Ember's announcement). Hopefully helpfully informing the release plans and strategy is all. 😄 Excited to participate in conversations around this topic and provide perspective and eventual documentation in this RFC. |
|
Note that
The lack of clarity and current churn makes the guarantee proposed by this RFC stronger than any existing ecosystem behavior which I find commendable. Whether that is reasonable is of course up for debate, thus the RFC. As a caveat, this urgency to get off of 0.10 and 0.12 may be a special case due to their age. We may not see this when we eventually drop 4.X support. |
|
Also worth noting: maintaining support for older nodes, even EOL'd ones, ensures that those stuck on those node versions have a smooth upgrade path. If both I really hope |
I thought part of the reason for publishing and forecasting the LTS, maintenance, and EOL dates was to give folks stuck on older versions a heads up and plenty of time for a smooth upgrade path. For example, the EOL of Node 0.10 was public ~1.5 years before it hit, similarly for v4, v6, etc. |
|
@jdalton yes, that's part of the plan. but just because that's the goal doesn't mean users universally do that. 0.10 is EOL now but plenty of people still use it in production - when their companies are ready to upgrade to 4, yarn (and hopefully all of their dependencies) won't add friction to that process, even if they're slower than the LTS plan desires. |
There's got to be a cut off at some time and I think the LTS and maintenance dates are good ones considering how much lead time they afford. Folks don't have to always use the latest and greatest packages and if they're truly stuck on an unmaintained Node version then they're likely resorting to dep pinning strategies anyway. |
|
Obviously a line must be drawn somewhere. I'm arguing that it's most beneficial to the users to support as far back as possible, even beyond official support dates. |
|
In other words, support for a platform shouldn't be dropped unless there's a very very good reason, and "i don't want to transpile" or "i want to use a shiny new feature but it's possible to implement without it" are not good reasons. |
Naw, that's impractical and unrealistic.
Teams don't have infinite bandwidth. Older enviros are a tax on testing, triage, and features. Following the LTS schedule is a good place to draw the support line. |
|
CI runs the tests on 0.10 just as easily as 0.12. There certainly may come a time when there's a cost - and that is the time to evaluate dropping support. But there's no value in dropping support as a matter of course. |
It's not free. Additional CI runs add to the cumulative test cost and support overhead. |
|
It runs in parallel and adds to travis-ci's costs, not the maintainers'. |
It's not that simple. Test fails can hold up PRs, complicating contributions, and they do incur a maintainer cost. Someone's got to track down those test fails after all. It's easy to suggest supporting as many versions as possible but it's a bit different when you're on the hook for that support. With the current LTS schedule that's a 1.5 year lead time for dropping older Node versions and supporting like four major versions of Node at a time. That seems totally reasonable. |
For every new Yarn release, or just for some legacy series of releases? What if we were to do something like dropping Node.js 0.10 support in Yarn 1.2.x, and Node.js 0.10 users could continue using Yarn 1.1.x and it'd only get major bug fixes (no new features)? If they're on a legacy Node.js version that no longer gets updates, it seems reasonable to do the same thing here too.
Do your sites support IE6? You don't need shiny features like SVG, flexbox, or border-box sizing, right? 😉
Older versions could have a lower level of support and just run nightly tests rather than having them run as part of every commit / pull request. I've already got a Jenkins instance running end-to-end tests for Yarn (spin up Ubuntu Docker container, install Yarn, run |
Sounds like you're volunteering to maintain them 😀, and that's cool. As mentioned the current LTS schedule seems totally reasonable on its own. |
|
I don't think I'd have enough time to maintain older versions, unfortunately. It was just a suggestion of one possible approach - I certainly don't think that legacy Node.js versions would have the same level of support as current ones 😄 |
|
@Daniel15 if you retain support by default, then let me know when you run into a problem maintaining support for an "old" version and I'll be happy to contribute the 20 minutes required to overcome the hurdle. |
If you'd like to run an unofficial fork to support unmaintained Node versions that could be rad. It shifts responsibility to someone like you, that's super energized for Node 0.10, 0.8, & so on while letting Yarn follow the LTS schedule. |
|
Lets focus on the contents of this RFC and discuss the more impactful details. I think it's a worthwhile goal to fully support versions of Node that are currently maintained, but I also don't see any need to intentionally break or refuse contributions to maintain support for older versions of Node. Should deprecated versions of Node be tested against in CI? I'm not sure I see a need for that. The community is upgrading to new versions of Node faster than ever before. Also, Yarn didn't exist in the days of 0.10 or 0.12, so I don't expect people who are unwilling or unable to upgrade to be amongst the early adopters of Yarn. That being said, it's a detail that doesn't really matter for the purposed of this RFC. If you want to talk about CI, open an issue in the main repo. It looks like we're only testing against 4 and 6 right now and we should probably expand that anyways. |
|
Note that with the hurdle of having a Node.js LTS policy for Yarn cleared Ember intends make official its support–which will bring an influx of users and maintainers (Hi!). We care deeply about the experience of our users and want for their experience to be the best possible. This carries over into the community projects we adopt–we're far from passive consumers. @jdalton I tend toward the opinion of @ljharb on this. Yarn should only ever support 4+ (given its release timing) and this RFC proposes supporting this for one additional year beyond the last day specified by the Node.js LTS date. This is of course negotiable and should be discussed at length amongst the Yarn core team as well as here. As long as Yarn meets or exceeds the Node.js LTS policy then anything beyond is a decision on how much to invest in increased effort for feature development versus returns in goodwill from the community. Anyway, just the resident policy wonk's opinions. |
I don't think yarn should necessarily follow npm's path.
There's already a 1.5 year heads up in place by the LTS policy, which is pretty generous.
I dig it. |
|
It seems to me that no one from the core contributors is willing to spend time on providing these guarantees. |
|
@bestander Realistically this isn't actually asking Yarn to make any changes, just to set a policy. That policy could be "YOLO, we could decide to stop supporting anything less than Node.js 7 tomorrow." It could be "We will support any version of Node.js which is still officially supported per the Node.js LTS Working Group." It could be the one I drafted here which is intentionally beyond the support of the Node.js LTS Working Group. Regardless of what the text of the policy says Yarn should present some policy to make it possible to communicate to the community the expectations they should have. That much is table stakes for a foundational infrastructure project. |
|
@nathanhammond you are right this would be desirable but right now putting a policy in place wouldn't affect anything. We simply don't have the resources to follow any one policy other than "fix and stabilize Yarn as much as possible". We should re-evaluate after that. Alternatively, if there are people that are willing to formally commit to uphold whatever policy we'd put in place, that would make it easier to merge this RFC. For example if there is a volunteer to support all Node LTS releases, we'd be supportive of this policy. |
|
@cpojer To my mind, an explicit policy could only help with the problem of limited resources. "Fix and stabilize Yarn as much as possible" is an inherently unbounded statement so it seems like it would make sense to constrain it to "fix and stabilize Yarn for Node version x+". That doesn't preclude expanding the range of supported versions at a later date, it just allows you to focus on a subset of the existing issues. |
|
@xtian: Just to be clear here; our plans for Yarn at Facebook have measurable goals internally at Facebook and one of them is to stabilize Yarn over the next couple of months. To that extent, we will focus on making Yarn work well for the version of Node we use at Facebook (currently Node 6 but may change any day). Yarn is an integral part of our internal JavaScript infrastructure and we need to make significant improvements still. Yarn is not a Facebook project, we merely have a seat at the table here rather than owning the table. From our perspective, we are willing to contribute as much to Yarn as we can but @bestander alone (the only person currently working full-time on solving third party JavaScript dependency management at Facebook) cannot uphold such a policy without help. Again, just to repeat, we are supportive of deciding on a real policy but we will need support from the rest of the community project. |
|
"Focus on making Yarn work well for the version of Node we use at Facebook (which may change any day)" is the implicit policy I had assumed for Yarn, but I think there is value in making it explicit as it can help the community make informed decisions and direct its effort to the areas where it is most needed. |
|
I'd rather hold off until we have a solid community driven core team. We don't see Yarn as a Facebook project. The problem we are solving at Facebook is third-party JavaScript dependency management. We are using Yarn to do that and will continue to contribute to the Yarn project. I'm ok if you refer other people to the conversation in this RFC for now but setting any sort of policy seems too early. |
|
I agree with @xtian's comment:
It would help y'all, and the community establish a set of expectations regarding what environments their changes should support, and which they may support. Furthermore, it allows other corporations, such as the one I belong to, to make informed decisions regarding whether to wholesale replace Stating that the Should that commitment change later, great, and if it doesn't, that's fine too. At the end of the day, you've communicated your intent, and everyone benefits as a result. Furthermore, to my knowledge, the RFC isn't a simple codification of what currently exists, but a statement of intent. So perhaps stating that the core |
|
@destroyerofbuilds at Facebook, currently we support node 6. Our integration tests range from node 4+. That's the current status but I cannot guarantee anything about how long we will support any one version of node at this time. |
I believe the only thing we really need commitment to, is that if node 4 support is dropped before node 4 is EOL, yarn does a major version bump. |
|
That is quite reasonable
…On Thu, 9 Feb 2017 at 14:01, Stefan Penner ***@***.***> wrote:
That's the current status but I cannot guarantee anything about how long
we will support any one version of node at this time.
I believe the only thing we really need,is that if node 4 support is
dropped before node 4 is EOL, yarn does a major version bump.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACBdWPnM-Xr9r7-sbXWf0wdNJeY4fs6Sks5ra4yjgaJpZM4KT604>
.
|
|
I think it's time to revisit this. A PR was opened to drop support for Node 4 when it reached EOL, yet it was decided that it should wait for a major version bump anyway. I'd suggest that we update this RFC to remove the 1 year after EOL guarantee, committing to only supporting current node versions. This would address the concerns raised about lacking resources to support older Node versions. We could also commit to a major version bump whenever support for a Node LTS release is dropped. This seems to be the plan for Node 4 anyway. I don't know if this is really necessary, but... it might be the least surprising course of action to take, from a user's perspective. While I do think it's reasonable to drop support for an EOL version of Node.js in a patch release, an average user probably doesn't know what our LTS policy is, and wouldn't expect anything to break after a minor or patch version change. Whatever we decide on that point, it's worth committing to something so that users know what to expect. |
|
Thanks for bringing this! I think the current status is that the next major bump will drop official Node 4 support for sure (it has become an actual pain point, both from the need to maintain two different builds and how it stops us from upgrading some of the third-party tools we use). The main question I think is about Node 6. It's EOL is April 2019, which isn't too far away. Maybe it would make sense to use the next major bump to drop support for Node 6 as well (in case of huge security issues we could still issue patches).
|
|
Waiting until April 2019 before releasing Yarn v2 would be fine with me. I don't think it's strictly necessary though. If we released v2 in the next month or two, we could easily wait until... May or June 2019 before v3, and still have a decent amount of work done in that 6 months for the release. I don't think it would be close enough to seem overly frequent. Either way, the larger question is whether a major version bump each year or so is acceptable or not, and whether dropping support for Node LTS releases should coincide with a major bump. I would be in favor of both, though I don't feel strongly about either. |
|
Imho trying to align with the LTS end of life is probably the best bet.
Dropping support prior to that point is a bit premature imho.
Keep in mind that 8.x EOL is a bit early, December 2019.
…On Mon, Oct 15, 2018, 4:32 PM Mark Stacey ***@***.*** wrote:
Waiting until April 2019 before releasing Yarn v2 would be fine with me. I
don't think it's strictly necessary though. If we released v2 in the next
month or two, we could easily wait until... May or June 2019 before v3, and
still have a decent amount of work done in that 6 months for the release. I
don't think it would be close enough to seem overly frequent.
Either way, the larger question is whether a major version bump each year
or so is acceptable or not, and whether dropping support for Node LTS
releases should coincide with a major bump. I would be in favor of both,
though I don't feel strongly about either.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAecV_qmomO9a94kIAm7lLsbHo13zi_Eks5ulPDSgaJpZM4KT604>
.
|
Rendered