Should we deliver new features in 1.2.x?

[He-Pin]

I think it will take time for us to release a 2.0.0, which only supports Java 17+. Should we deliver features in 1.2.x and then forward-port to 2.0.0?

[raboof]

I think it's fine to have features land in 1.2.x (update) 1.x while we're working towards 2.x on main.

I would prefer first landing them in main and then back-porting to 1.x: the risk with 'forward-porting' is that we might forget, causing a 'regression' in 2.x . This is true even when we make porting easier with tools like Mergify. Forgetting a backport is less problematic compared to forgetting a forward-port.

[mdedetrich]

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).

[mdedetrich]

So to start off with, I don't think it was ever the plan that development on the 1.x series of Pekko would cease just because we started working on 2.0.0 on main. 2.0.0 will take a while and at least myself (and I would even go as far to say as the rest of the community) was under the impression that the 1.x series would continue to develop as normal.

The question here is, what process should we have regarding general features/bugs/fixes for the 1.x series. Should we baes the PR first off of 2.0.x and then backport it to 1.2.x/1.3.x etc etc or should these general PR's target 1.2.x/1.3.x as a branch and then forward port it.

There are pros and cos to each, with the forward porting there is a risk that we may forget a regression (as pointed out by @raboof ) but its a lot easier to make such a PR, especially if it touches code that has been modified as a specific 2.0.0 change. Its also clearer what the intent of the PR is, if it targets a 1.x branch then its a general feature but if the PR is a 2.0.0 specific change (i.e. dropping Scala 2.12, removing deprecated methods etc etc) then it targets main branch.

I personally don't mind either way, just that it should be clear which approach to use.

[He-Pin]

I think we should add features on main and then backport to 1.2.x, I was thinking only bugfixes can be shipped to 1.2.x.

[pjfanning]

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.

[He-Pin]

Yeah，Seems 2 months is reasonable

[pjfanning]

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.

[pjfanning]

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.

[mdedetrich]

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.