As a corollary, you could argue that if you make a PR in main you can forget to backport it to 1.2.x/1.3.x which means that the feature gets lost and would never get tested, yet alone realized, until 2.0.0 gets released. Also unless the PR is clearly signaling whether its a unique 2.0.x feature or not it does increase friction (although tbh that friction should be practically minimal).

I would prefer to get a 2.0.0-M1 out in maybe 2 weeks and a 2.0.0-M2 2 months after that. We can decide then if we want to aim at a 2.0.0-M3 or if we want say that we have enough done to justify a 2.0.0 full release.

Yeah,Seems 2 months is reasonable

With 1.x, I think 1.2.x should be mainly for bug fixes, important dependency upgrades (as long as they are not big bumps) and doc fixes. I don't mind adding some deprecations.
If we are talking about new features, then we should consider going for a 1.3.0 release. I'm flexible enough if the changes are small but non-trivial improvements should probably mean that we do a minor release instead of a patch release. It is no more difficult to do a 1.3.0 release than a 1.2.0 release.

We've already reached a stage where 1.0.x patch releases are very unlikely unless users come along with very meaningful reasons as to why they need bug fixes and patch releases to 1.0.x instead of upgrading. I think 1.1.x will reach that stage too in a few months (if we see no major issues in 1.2.x). So I'm not worried about pushing through 1.3.x and 1.4.x releases. We don't need to stay on 1.2.x indefinitely.

The changes in 2.0.0 are likely to mean that we have lib maintainers who don't release Pekko 2 compatible libs. Generally, we're going to have users who don't want to spend time switching over.
We are likely to end up a bit like Scala where we have a large proportion of users sticking with 1.x - probably a majority for the first year or more after a full Pekko 2.0.0 release.

With 1.x, I think 1.2.x should be mainly for bug fixes, important dependency upgrades (as long as they are not big bumps) and doc fixes. I don't mind adding some deprecations. If we are talking about new features, then we should consider going for a 1.3.0 release. I'm flexible enough if the changes are small but non-trivial improvements should probably mean that we do a minor release instead of a patch release. It is no more difficult to do a 1.3.0 release than a 1.2.0 release.

According to semver, for 1.2.x series (since its already released) only patch updates are allowed which is basically bug fixes. New deprecations and important dependency updates would be for 1.3.x

We've already reached a stage where 1.0.x patch releases are very unlikely unless users come along with very meaningful reasons as to why they need bug fixes and patch releases to 1.0.x instead of upgrading. I think 1.1.x will reach that stage too in a few months (if we see no major issues in 1.2.x). So I'm not worried about pushing through 1.3.x and 1.4.x releases. We don't need to stay on 1.2.x indefinitely.

Agreed, in fact we already have new features in the pipeline right now that asks for 1.3.x

The changes in 2.0.0 are likely to mean that we have lib maintainers who don't release Pekko 2 compatible libs. Generally, we're going to have users who don't want to spend time switching over. We are likely to end up a bit like Scala where we have a large proportion of users sticking with 1.x - probably a majority for the first year or more after a full Pekko 2.0.0 release.

Definitely, which is another reason why we need to continue managing 1.x series. Its hard to predict how extreme the discrepancy of users only running on 1.x will be, but years is a good back of envelope figure.