[best practices] managing LTS & release lines for userland modules

[boneskull]

I'm starting a discussion in Mocha around how we can best support multiple "LTS" release lines.

I'm familiar with what Node.js itself does (though I haven't ever cut a Node.js release myself; it seems essentially like trunk-based development). But I don't have an understanding of all the gotchas around something like this.

It does seem that, without proper tooling, maintainers will be in for a lot of pain in addition to the extra overhead that the strategy initially incurs.

I also don't know how other teams/projects that want to do long-lived release lines do it, and would love to hear from them!

How can we, as the package maintenance team, help projects that want to take this on? What works and what doesn't?

[boneskull]

(I wonder if @bethgriggs might have some insight?)

[mcollina]

We are currently doing this in Fastify with v1 and v2. It’s not super straightforward, especially in handling backports in a semi-automated way.

[dominykas]

I like how semantic-release (v16, beta, not latest) solves it. Already put it in practice at work, at small scale to test - people mostly like it.

It is rather opinionated, though, so might not always be feasible.

I'm curious to hear more about what seems to be the issue?

[mhdawson]

@mcollina any details on what you are doing that you can share that might be input for this discussion ?

[boneskull]

For automating backports, maybe something like a GH Action which runs a post-commit hook against a given branch (e.g., master) that will automatically cherry-pick the changeset(s) to release branches if it passes CI? Otherwise maybe create an open PR someone can hack on? Really wouldn't know if this sort of thing would be too burdensome or failure-prone until it was up & running...

[ljharb]

In my experience, backports very rarely land cleanly, even if there's no git conflicts - it's always required a trivial bit of human tweaking.

[mcollina]

In Fastify we are currently maintaining two release lines, v1 and v2. We have no automated tool for backporting. As such, we require a backport from the original author or the PR or from the developer landing the PR - or if there is a need.

It’s a lot free form, and a bit of automation will help.

[wesleytodd]

In my experience, backports very rarely land cleanly, even if there's no git conflicts - it's always required a trivial bit of human tweaking.

👍 Only trivial changes are able to be backported in an automated way. I am not sure how much automation will be possible here, but would love to see a POC on the idea.

In Fastify we are currently maintaining two release lines, v1 and v2. We have no automated tool for backporting. As such, we require a backport from the original author or the PR or from the developer landing the PR - or if there is a need.

In Express we do the same as @mcollina mentions that Fastify does. As an example of one backporting effort I am involved in:

https://github.com/expressjs/express/pull/3714 https://github.com/expressjs/express/pull/3218

As you can see, the changes are quite different, and any automated backport would not have worked. That being said, any help here would have been great, because the complexity in backporting meant that this sat for quite a while without being merged, and is still in a bit of limbo.

[balupton]

copy of my comment here https://github.com/nodejs/package-maintenance/issues/280#issuecomment-554855494

---

FWIW

@bevry accomplishes the goal of this automatically for all of its packages, through the following pieces

• https://github.com/bevry/boundation enforces consistency against packages, including support for all the below, and including support for local testing on the package's specified node versions via https://github.com/bevry/testen
  • https://github.com/bevry/editions enables support for older node versions, as well as provides standardised data about the environments the package supports and what technology it uses
  • https://github.com/bevry/projectz enforces consistency of the meta files, such as the readme and package.json, and installation and license information, including badge information via https://github.com/bevry/badges
  • https://github.com/bevry/awesome-travis has several scripts such as
  • https://github.com/bevry/awesome-travis/blob/master/scripts/surge.bash which publishes the commit, branch, and tag to surge for browsing of docs and cdn
  • https://github.com/bevry/awesome-travis/blob/master/scripts/node-publish.bash publishes git tags to latest and master (as configured by NPM_BRANCH_TAG) to the next tag
  • https://github.com/bevry/awesome-travis/blob/master/scripts/node-install.bash ensures dev deps are installed with the desired node version, to enable tests to run even on legacy node versions
  • dependabot configuration to auto-merge passing dependency updates
• https://github.com/balupton/dotfiles/blob/master/.scripts/users/balupton/commands/boundation-upgrade runs boundation on a project, and publishes a new release - if the engines changed, publishes a new major release, otherwise a minor
• https://github.com/balupton/dotfiles/blob/master/.scripts/users/balupton/commands/boundation-all runs boundation-upgrade on all bevry's packages

[dominykas]

Adding this to agenda, if time permits - maybe we can visit this as part of #289

I'm wondering what can we do to move this forward?

• From the discussions here, it seems the feeling is that automated backporting probably has a very low ROI
• We could have a best practice document on various source control approaches to achieve multiple release lines in a project, but I figure there's probably a lot of similar documents already out in the world, so maybe from the perspective of this WG, just a list of links to some articles is good enough?
• There's definitely some tooling that's useful when maintaining multiple major release lines. semantic-release has support for that (can't recall if it's only in the beta or in latest as well), there's probably some other tools/conventions that we can write up, but I wonder if we want to have a separate "this is how you do LTS" doc or if it fits better under existing publishing and versioning guidelines?

[Eomm]

just a list of links to some articles is good enough?

We could start from that and then add a TOC in order to ease the learning process for the maintainers

[dominykas]

Some specific things our LTS doc should mention:

• aligning to Node LTS, not bumping major
• including the support levels
• https://github.com/CloudNativeJS/ModuleLTS/blob/master/README.md