Branch and release plans for 2.x now that we're using semver

Open a 2.1.x branch.
All issues + MRs should target that from here on out.
We backport bug fixes and non-disruptive tasks (like test improvements) to 2.0.x when appropriate (ideally via cherry-pick).
We tag and ship 2.0.x releases as needed.

Makes sense to me.
I'm also fine with not backporting fixes to 2.0.x once there's a 2.1.0 release, we want people to stay on the latest minor version.

Discuss if we want to aim for a ~yearly minor release schedule, or otherwise start to think about when we want to do a 2.1.0 release (with alpha, beta, rc, etc).

I wouldn't try to create a fixed schedule for minor releases, since neither of us is paid to work on Address, we can't guarantee when we'll be active. We might be able to do two minor releases one year, then nothing for another year. It's fine to say "once there's enough in a branch to release, we release".

We could also open 2.x branch now and use that as ‘main’, like core is doing with 11.x, so we don’t have as much version and MR churn once we do decide to branch 2.1.x and move to a new stable release.

Totally agree on not committing to a release schedule if neither of us are paid to do this. 😂

We could also open 2.x branch now and use that as ‘main’, like core is doing with 11.x, so we don’t have as much version and MR churn once we do decide to branch 2.1.x and move to a new stable release.

I am fine with that if that's what you prefer. Leaving the decision to you.

This is a low-traffic module (~100 open issues, ~20 of which have patches or MRs), so whatever we choose will be manageable.

Yeah, I think 2.x branch is better as "main", and we only open minor-specific branches once something is RC or something. Less version churn.

We can decide if we want to support 2 stable branches (like core) or just 1. I don't mind supporting 2, hopefully it won't be that much work. As you say, this is a fairly "complete" module that doesn't have that much development "traffic". Ideally, bug fixes will easily cherry-pick across branches. Having solid tests configured on a wide matrix of core versions will give us high confidence that if the tests are still green, we can cut releases at will.

Made a 2.x branch and a 2.x-dev release with the same warnings as 11.x:
https://www.drupal.org/project/address/releases/2.x-dev →

Cool, thanks.

Yeah, the tooling is a bit clunky. But -dev releases are all kinds of problems, anyway, all the more for this project which needs to be installed via composer, anyway. That said:

1. We'll backport bug fixes and non-disruptive tasks to 2.0.x immediately
2. We can always start tagging 2.1.0-alphaN releases from the 2.x branch whenever we want, even before we branch 2.1.x
3. Folks that truly want to be on bleeding edge can get composer to install directly from Git

Automatically closed - issue fixed for 2 weeks with no activity.