Maintaining multiple release branches

[aladdin-add]

eslint-plugin-n version

v17

What problem do you want to solve?

We are preparing the release of v18, which may take a long time; but currently, this package only has one release branch - master.

What do you think is the correct solution?

My idea is:

1. Cut a new release branch v17.x (to be kept in maintenance mode ~6 months)
2. Merge breaking changes on the main branch
3. Backport compatible updates from the main branch to v17.x

We may need to modify the release process (e.g. release-please) to support this.

Disadvantages:

• We have to spend more on maintenance costs.

Participation

• I am willing to submit a pull request for this change.

Additional comments

No response

[aladdin-add]

cc / @eslint-community/eslint-plugin-node @scagood

[MichaelDeBoey]

@michaelfaith this is one of the reasons why I wanted to still be able to have alpha/beta releases in eslint-utils (see eslint-community/eslint-utils#294 (comment)).

You mentioned you probably had some solutions.
Could you please give us some some insights into these possible solutions?

[michaelfaith]

This is what I'm piloting in one of the repos I collab with Josh on: michaelfaith/package-json-validator@main...beta

Here's an example of a beta release PR: michaelfaith/package-json-validator#650

tl;dr, each release branch has its own release-please config, and the release workflow uses the branch name to load the appropriate config. There's also logic to determine which dist-tag to use for the publish, based on the release that release-please did. That logic does not depend on the name of the branch (only the loading of the config does). Our plan is to publish beta releases from dedicated branch, but publish rc releases from main after merging beta. And we'll just update the main config to create rc releases, until we're ready to pull the trigger. The rc cycle should be short enough for those to run out of main.

I'll be rolling this out to eslint-plugin-package-json once we make it through the 1.0 release in this repo (we're aiming to release the latter's 1.0 in April, whereas pjv is going to 1.0 in Feb; so we're going to test the workflow in this repo and then roll it out to the rest).

[voxpelli]

I like this (mentioned similar in eg. #502 (comment))

Especially having a "current" and "maintenance" branch similar to ESLint (https://eslint.org/version-support/) makes a lot of sense

And if we split out the compatibility data (#511) and keeps that compatible with both versions, then things probably get even easier

[michaelfaith]

If you went with current / maintenance instead of current / next, you could still use a similar approach as I described above, it just wouldn't involve the prerelease properties. And the maintenance branch (as a whole) wouldn't be merged back into main like the beta branch strategy would involve. The main challenge that's different with this approach vs a current / next is that you effectively have to make maintenance changes twice (once in main and then separately in maintenance). But then you wouldn't have the chore of rebasing maintenance onto main periodically like you would with beta. So maybe it's a wash? Both seem like it would solve your need, just in different ways.

[MichaelDeBoey]

What would be the benefit of having a maintenance branch if you're going to backport all changes from main anyways?

If I understand it correctly, the only "benefit" would be pushing people towards a next ESLint version, but the maintainers would have more work (needing to push to both main & maintenance), so imo this is more like a disadvantage tbh

[voxpelli]

A maintenance branch would imply only backporting selectively – mainly important bug fixes – to ensure it's a functional option, but not an actively developed version

[michaelfaith]

Sharing this, since I just finished getting this all worked out in package-json-validator. You can see how we now have -beta versions publishing under the beta dist-tag alongside regular release versions going to the latest dist-tag

For a "maintenance" branch approach, the config and workflow would be slightly simpler