Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node.js LTS Policy #1

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nathanhammond
Copy link

@nathanhammond
Copy link
Author

For awareness, /cc @thealphanerd

@MylesBorins
Copy link

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

@nathanhammond nathanhammond Oct 12, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@Daniel15 Daniel15 Oct 13, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

@nathanhammond nathanhammond Oct 13, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How will the LTS branch's of yarn be handled? Will there be an active + maintenance period for backporting?

@jamiebuilds
Copy link
Contributor

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.

@nathanhammond
Copy link
Author

@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.

@nathanhammond
Copy link
Author

nathanhammond commented Nov 9, 2016

Note that npm appears to have elected to follow the Node.js LTS guarantee and dropped 0.10. However, it has additionally dropped 0.12 from testing: npm/npm#14503

npm's LTS strategy lacks a tremendous amount of concrete detail:

  • npm has no stated explicit degree of support for their versions as tied to the Node.js LTS versions.
  • Secondarily (and not explicitly related to this RFC) npm has no stated explicit support timeline guarantees attached to their own version releases.

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.

/cc @othiym23 @seldo

@ljharb
Copy link

ljharb commented Nov 9, 2016

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 npm and yarn stop working on node 4, then that may mean many people are stuck on node 4 forever, because they'd have to coordinate both a node and npm/yarn upgrade simultaneously.

I really hope yarn is very very cautious in dropping support for platforms it currently supports, unrelated to LTS schedules.

@jdalton
Copy link

jdalton commented Nov 9, 2016

@ljharb

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.

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.

@ljharb
Copy link

ljharb commented Nov 10, 2016

@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.

@jdalton
Copy link

jdalton commented Nov 10, 2016

@ljharb

but just because that's the goal doesn't mean users universally do that. 0.10 is EOL

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.

@ljharb
Copy link

ljharb commented Nov 10, 2016

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.

@ljharb
Copy link

ljharb commented Nov 10, 2016

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.

@jdalton
Copy link

jdalton commented Nov 10, 2016

@ljharb

I'm arguing that it's most beneficial to the users to support as far back as possible,

Naw, that's impractical and unrealistic.

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.

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.
Currently that means testing 0.12, 4, 6, & 7 which is a pretty good amount.

@ljharb
Copy link

ljharb commented Nov 10, 2016

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.

@jdalton
Copy link

jdalton commented Nov 10, 2016

@ljharb

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.

It's not free. Additional CI runs add to the cumulative test cost and support overhead.

@ljharb
Copy link

ljharb commented Nov 10, 2016

It runs in parallel and adds to travis-ci's costs, not the maintainers'.

@jdalton
Copy link

jdalton commented Nov 10, 2016

@ljharb

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.

@Daniel15
Copy link
Member

Daniel15 commented Nov 10, 2016

I'm arguing that it's most beneficial to the users to support as far back as possible,

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.

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.

Do your sites support IE6? You don't need shiny features like SVG, flexbox, or border-box sizing, right? 😉

It's not free. Additional CI runs add to the cumulative test cost and support overhead.

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 yarn add react, ensure it works), we could have "super legacy Node.js testing" run nightly too.

@jdalton
Copy link

jdalton commented Nov 10, 2016

@Daniel15

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.

Sounds like you're volunteering to maintain them 😀, and that's cool.
But as Yarn's open issues creep towards the 400's I think it's going to be a drag.

As mentioned the current LTS schedule seems totally reasonable on its own.

@Daniel15
Copy link
Member

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 😄

@ljharb
Copy link

ljharb commented Nov 10, 2016

@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.

@jdalton
Copy link

jdalton commented Nov 10, 2016

@ljharb

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.

@jamiebuilds
Copy link
Contributor

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.

@nathanhammond
Copy link
Author

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. npm didn't drop support for 0.8 until June of this year. The drop of 0.10 already as well as the (seemingly) early drop of 0.12 came as a surprise to me (ping me out of band if you want to hear unfiltered thoughts on the matter). One place where I want to be careful: I firmly believe that untested == unsupported. It's far too simple to use an unsupported language feature and find yourself with a non-working build.

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.

@jdalton
Copy link

jdalton commented Nov 10, 2016

@nathanhammond

npm didn't drop support for 0.8 until June of this year.

I don't think yarn should necessarily follow npm's path.

this RFC proposes supporting this for one additional year beyond the last day specified by the Node.js LTS date.

There's already a 1.5 year heads up in place by the LTS policy, which is pretty generous.
Adding another year, making that a 2.5 year heads up, seems a bit drawn out.

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.

I dig it.

@bestander
Copy link
Member

bestander commented Jan 17, 2017

It seems to me that no one from the core contributors is willing to spend time on providing these guarantees.
Unless someone is willing to contribute by keeping track of issues, setting up and maintaining CI and promoting wider Node.js compatibility I think we should close this RFC.

@nathanhammond
Copy link
Author

@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.

@cpojer
Copy link

cpojer commented Jan 17, 2017

@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.

@xtian
Copy link

xtian commented Jan 17, 2017

@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.

@cpojer
Copy link

cpojer commented Jan 17, 2017

@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.

@xtian
Copy link

xtian commented Jan 17, 2017

"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.

@cpojer
Copy link

cpojer commented Jan 17, 2017

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.

@ghost
Copy link

ghost commented Feb 6, 2017

I agree with @xtian's comment:

To my mind, an explicit policy could only help with the problem of limited resources.

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 npm with yarn.

Stating that the yarn core team will prioritize only Node 6 provides the information I need to make a decision, because the company I work for requires our tooling to support both Node 4 and Node 6. If the yarn core team can only commit to Node 6, then it's quite easy to make the decision that we can't switch wholesale, because we can't afford yarn intentionally making the decision to break Node 4 tomorrow.

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 yarn team wants to support Node 4 and Node 6 is fine as well, even if all features in yarn don't work on Node 4. At least then I know that I can use yarn on Node 4, and if I encounter a problem, and submit a fix to yarn, I can expect that the core team will be receptive to incorporating that fix.

@cpojer
Copy link

cpojer commented Feb 7, 2017

@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.

@stefanpenner
Copy link

stefanpenner commented Feb 9, 2017

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.

@bestander
Copy link
Member

bestander commented Feb 9, 2017 via email

@BYK BYK self-assigned this Sep 29, 2017
@BYK BYK removed their assignment Oct 6, 2017
@Gudahtt
Copy link
Member

Gudahtt commented Oct 15, 2018

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.

@arcanis
Copy link
Member

arcanis commented Oct 15, 2018

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).


@Gudahtt
Copy link
Member

Gudahtt commented Oct 15, 2018

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.

@MylesBorins
Copy link

MylesBorins commented Oct 16, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.