Proposal: Initial "Active LTS" release should follow LTS policies

[schmod]

Apologies if this is not the correct forum for this discussion. Please feel free to close this issue or point me to the correct location.

The first "Active LTS" release of the 8.x series, v8.9.0 dropped this week, and included several additions that would not typically be incorporated into an LTS release (or otherwise would have been required to be introduced to spend at least 2 weeks in the wild in a Current release).

Specifically, util.textEncoder and util.textDecoder were moved out of "Experimental" status. One week prior, the entire http2 module was moved out from behind a flag.

While I have full confidence in the community's ability to vet and test experimental features, the late-breaking additions feel a little bit like we crammed the night before the test, and betrays the stability guarantees that the LTS series is meant to provide.

---

I'd like to propose a new guideline that encourages the first "Active LTS" release of a major nodejs version to follow the same set of guidelines that we already follow for subsequent "Active LTS" releases:

Changes in an LTS-covered major version are limited to:

1. Bug fixes;
2. Security updates;
3. Non-semver-major npm updates;
4. Relevant documentation updates;
5. Certain performance improvements where the risk of breaking existing applications is minimal;
6. Changes that introduce large amount of code churn where the risk of breaking existing applications is low and where the change in question may significantly ease the ability to backport future changes due to the reduction in diff noise.

Generally changes are expected to live in a Current release for at least 2 weeks before being backported. It is possible for a commit to land earlier at the discretion of the Release working group and the maintainers of the LTS branches.

Effectively, this would introduce a 2-week freeze on new features prior to an initial LTS release, which would only contain bugfixes and minor changes from the prior release (likely making the initial LTS drop a semver-minor release).

To prevent this change from reducing the overall momentum and release cadence of the project, it might be ideal to introduce the new Current series 2-4 weeks ahead of an initial Active LTS release. This way, we won't create a window during which it isn't permissible to introduce new features.

---

A hypothetical alternative timeline would have looked something like this:

• 30-Sept-2017 9.0.0 is released, and becomes the new Current.
• 17-October-2017 8.9.0 and 9.0.1 are released. 8.9.0 contains bugfixes from 8.8.x, and any non-semver-major backports from 9.0.0 and 9.0.1.
• 31-October-2017 8.9.1 and 9.0.2 are released. 8.9.1 is now Active LTS, and conforms to all of the things that we expect to see from an LTS release. It contains bugfixes, and non-semver-major backports from 9.0.0 and 9.0.1. Backports from 9.0.2 may not be released into the 8.x series until 14-Nov.

[gibfahn]

This is the right place, but this discussion is already happening in #279, so it might be best to continue in there (at least for now).

[schmod]

Not sure how I missed that. Will move the conversation over there!