meta: LTS strategy

[boneskull]

To support "LTS"--or long-running releases--we will need to make some development workflow changes.

In terms of a branching strategy, I'm thinking the most reasonable approach would be trunk-based development, which I had experimented with before without knowing what it was called. Node.js uses something very similar to this.

In a nutshell:

• all development work is done targeting master (except in the case that the bug cannot be reproduced in master; it then must happen on release branches)
• each LTS release (e.g., each major or even-numbered majors) branches from master
• bug fixes, features, etc. are cherry-picked from master into the release branch
• releases are tagged from the release branches, not master
• "feature" branches exist how we've been doing them--no change here. these are any short-lived branches to be rebased onto master and merged via a PR. note that this includes bug fixes, "chores"--pretty much anything.
• in the case that work must be done against a release branch, a PR should target that branch, and cherry-picked from release into master, if it makes sense.
• at no point is a release branch ever merged back into master.

In addition to whatever we're going to get from users reporting bugs against multiple release lines, this is the overhead we're looking at for LTS releases. There are some tools available which we can either use outright or adapt for our uses (from the Node.js project), but we may need a purpose-built solution. For example, it'd maybe make sense to automatically attempt cherry-picking of new changesets in master into the active release branches.

(AFAIK, cherry-picking is used because otherwise each changeset in master would create an extra merge commit when pulled into an active release branch.)

A noted headache is cross-referencing changesets with their original PRs (due to the loss of context created when a changeset is cherry-picked instead of merged). It becomes critical to link to the PR number somewhere in the commit message. Of course, you can't add the PR to the commit message when you create a changeset, so the commit message must be amended at time-of-merge. Node.js also has tooling (and a convention) around this.

---

Another unconventional way to tackle this is to literally snapshot the codebase for each release line and stuff it in some subdirectory. I'm pretty sure I didn't just dream this up. Anyway, I don't think the tooling's there to support this sort of thing, though at its core, it sounds similar to a monorepo. The major challenge would be to coordinate patch application across multiple directories, assuming something like Lerna could manage the rest of it. While the above branching solution is non-trivial, I still don't see a clear advantage; both will require tooling.

cc @mochajs/core

[boneskull]

would love input or suggestions from anyone in @nodejs/package-maintenance or @nodejs/release

[boneskull]

I'll create some issues there for cross-reference

[juergba]

There will still be only one single master branch.
So it doesn't make sense talking about ceiling our IE11 support to some release version. I was hoping we could use LTS to park IE11 support in LTS v6.x.x and continue our development with ES6 in v7 without IE11.
Just a beautiful dream, right?

[plroebuck]

So it doesn't make sense talking about ceiling our IE11 support to some release version. I was hoping we could use LTS to park IE11 support in LTS v6.x.x and continue our development with ES6 in v7 without IE11.

Several projects I've seen are simply moving to ES6 and requiring Babel to support IE.

[plroebuck]

Note also that this merge style will need each PR to be much more focused.
No more adding tangential changes... just exactly what the PR's description calls for.

[craigtaub]

Conventional process sounds solid.

Development for contributors seems largely the same except if bug only against specific release, will have to document process, I'm sure that's part of the plan.

More tooling (i.e. cherry-pick latest changesets for release branch) sounds really useful, I'm wondering if we can use it for changelog. Not crucial at this point.

[boneskull]

IMO the changelogs must be written manually. It’d be nice to pre-fill it with the list of commits/PRs though, so we at least have a place to start.

[boneskull]

The drawback of dropping IE support is that it will become more difficult to cherry-pick fixes, since ostensibly we will want to modernize our codebase. We could also just not worry about backporting anything and only apply critical fixes. It really kind of depends on what the foundation requires, but we should shoot for minimizing what we must backport to an old release line.

Thankfully Mocha isn’t run in production, so the bar for “critical fix” is pretty high.

[outsideris]

I like to support LTS releases while I don't have much experience for LTS release.

[boneskull]

We can't really settle on an LTS strategy until we've discussed this with the Foundation. However, we can propose something.

I think we can also leverage GitHub Actions to help.

[boneskull]

ref: nodejs/Release#451

[craigtaub]

In here sounds like we are in relative agreement on the process (i.e. trunk-based). Is next step to formalise?
Also this should probably move to admin repo.

[juergba]

Thinking about this trunk-based development:
actually it's our current way of working. If I want to fix a bug, I create my own branch - a copy of master, fix the bug and then merge my changes back into master.

But for LTS this is not a good way to develop. Let's say we drop IE11 support for v7. After short time our master branch (without IE11) will look completely different from our release/v6.*.* branch (with IE11). We will have to maintain both branches separately as independent masters, the main master and release/v6.*.* master.

[juergba]

I strongly doubt that Node has one master and with that trunk maintains all its LTS releases v10, v8.

[juergba]

I had a look at Node's GH repository. If I got it right, they don't use trunk-based development. Currently they have three "master" branches which are maintained independently by separate PR's. Cherry-picking seems to be used just for the newest release v12.

They have following branches:

• master: current working branch. Probably not locked against forced pushes (no keyhole sign)
• v12.x: commits seem to be cherry-picked from master, not locked
• v10.x: no cherry-picking, commits point to PR's targeting this branch (not master), locked.
• v8.x: no cherry-picking, commits point to PR's targeting this branch (not master), locked.