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: JoshuaKGoldberg/package-json-validator@main...beta

Here's an example of a beta release PR: JoshuaKGoldberg/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).