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.

Sign up for GitHub

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

Jump to bottom

Node.js LTS Policy #1

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

Node.js LTS Policy #1

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
35 changes: 35 additions & 0 deletions text/0000-lts-policy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
- Start Date: 2016-10-11
- RFC PR: (leave this empty)
- Yarn Issue: (leave this empty)

# Summary

Yarn must have a Node.js compatibility story which enables it to be used in enterprises and side projects everywhere.

# Motivation

A package manager must have an incredibly detailed support plan for the community which it serves. It must do this as the foundation for building tools within the ecosystem. This support plan will likely need to _exceed_ the [support guarantees of the underlying ecosystem](https://github.com/nodejs/LTS).

# 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.
Copy link

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

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 •
edited

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

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.


Yarn may drop support in a _patch_ update per SemVer.

# How We Teach This

The answer is simply communication. This should appear in blog posts, tweets, and documentation on the website. The Yarn team should participate in the Node.js LTS WG.

# Drawbacks

The costs of an extended support model are borne by those who maintain the project. This takes a tremendous amount of effort and discipline and means that we don't get the newest features of JavaScript. This is a tradeoff that we must make as a consequence of being a foundational tool.

# Alternatives

As an alternative we could adopt a policy which explicitly matches the Node.js LTS policy. This maps to [other Node.js ecosystem projects such as Ember](http://emberjs.com/blog/2016/09/07/ember-node-lts-support.html).

Not setting a strategy is not a viable option when we have enterprises which need to be able to follow a known predictable schedule for their updates.

# Unresolved questions

How much appetite is there in to maintain this project in legacy versions of Node.js?
Copy link

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?