## Goals

Our policies should:

1. Offer a feature track for landing features more quickly
2. Offer a safety track where stability is the top priority
3. Do the above without unacceptable increases to maintenance burden

# Proposal: A Modified [Node Support Policy](https://github.com/nodejs/Release)

Unlike Node, **Electron should not offer LTS versions** because Chomium does not offer LTS and we cannot do that work ourselves.

Setting duration aside, though, Node's *other* LTS policies address the 'feature' and 'safety' tracks goals I mentioned. So:

* Even-numbered major releases behave like [Node LTS active maintenance.](https://github.com/nodejs/Release#release-plan) (tldr: bugfixes, security, doc fixes, diff shear reducton. Some low-risk performance wins.)
* Even-numbered major releases are supported for 9 months. (This is what we already do via our support-three-versions policy)
* Odd-numbered major versions follow a [TBD](https://hackmd.io/0DlgmOvqS9yLtTHyjIT1HQ) policy that releases-wg will decide, but which welcomes `semver minor` features.
* Odd-numbered releases are EOL after the next even-numbered release goes stable.
* **Maybe** call even-numbered major versions **"MTS"** (medium-term support).
* :heavy_plus_sign: this is a low-friction way of succinctly communicating all the above tradeoffs
* :heavy_plus_sign: "MTS" is relatively easy to understand even upon first hearing
* :heavy_minus_sign: invites low-effort heckling from the haters
* :shrug: but seriously, who cares about the haters
* Document it so users can make informed decisions & find the track they want

### Expected Outcomes

* :heavy_plus_sign: Clearly-defined feature and safety tracks
* :heavy_plus_sign: Better opportunities for landing new features quickly
* :heavy_plus_sign: A policy that, thanks to Node, devs and users can understand
* :heavy_plus_sign: A policy that, thanks to Node, is field-tested
* :heavy_plus_sign: Cheaper maintenance costs due to EOL of odd-numbered releases
* :heavy_minus_sign: Slightly more complex than existing policy
* :shrug: feature track is improved in odd-numbered releases, but not during MTS cycles

## Why?

The first two proposals in the Feb/Mar Releases meetings are:

1. "When a new minor series is released, the previous minor series is discontinued." (e.g. 9.4.x becomes unsupported when 9.5.0 comes out). ([Approved by vote](https://github.com/electron/electron/pull/22613/files))
2. "[Minor all the things](https://github.com/electron/governance/blob/master/wg-releases/meeting-notes/2020-02-26.md#agenda): If there are safe semver minor features that would like to be released in a minor version, we should release it"

When these two changes interact, users have no way of getting bugfixes without new features because the bugfix branch is discontinued. This is a regression to the Electron 1.x practices [that prompted us](https://github.com/electron/electron/commit/06371a6082bd79243d7c26c6d3cb893bbdc61288) to [adopt semver](https://github.com/electron/electron/blob/master/docs/tutorial/electron-versioning.md):

> While convenient for developers merging features, it creates problems for developers of client-facing applications. The QA testing cycles of major apps like Slack, Stride, Teams, Skype, VS Code, Atom, and Desktop can be lengthy and stability is a highly desired outcome. There is a high risk in adopting new features while trying to absorb bug fixes.
>
> An app developed with 1.8.1 cannot take the 1.8.3 bug fix without either absorbing the 1.8.2 feature, or by backporting the fix and maintaining a new release line.

"Minor all the things" + "Previous minor series [are] discontinued" is functionally equivalent to that 1.8.x state because users must take new features to get fixes. At least semver makes that problem explicit now, but the problem is still there.

Our top user complaint is that Electron's treadmill is already too difficult to keep up with. That is our current baseline.

"Minor all the things" + "Previous minor series [are] discontinued" makes that baseline *worse*, not better.

## Discarded Ideas

* Leave everything as it is
* Does not offer a feature track for releasing features more quickly
* As-is but add "[Minor all the Things](https://github.com/electron/governance/blob/master/wg-releases/meeting-notes/2020-02-26.md#agenda)"
* Does not offer a safety track
* As-is but make `semver minor` backports more permissive
* Does not offer a safety track
* Copy Node's LTS policy
* Chromium does not offer an LTS
* Support "0 minor" series alongside the latest version: e.g. 9-0-x stays alive & gets bugfixes as long as 9 is supported
* Doubles the number of maintained branches