> Some of those changes will likely also need backporting for 1.0.x releases.
Indeed, the rolling migration from Akka to Pekko clusters is actually a feature for 1.0.x, but because of how its designed (i.e. there is a configuration for the sender/receiver address), this feature and configuration also needs to exist for Pekko 1.1.0 otherwise the user experience will be extremely unintuitive. > I don't think a 1.1.0-M0 is warranted. This git tag has code that is very similar to Pekko 1.0.1. I don't see the merit in having multiple ASF contributors having to review such a release. It trivializes MiMa management which is worth the annoyance of doing a release. There really isn't any other way without breaking ASF policy, we basically have to make a release that is not a "real" release. One thing to note is this doesn't occur that frequently (i.e. M0 milestones), i.e. its only on a minor version bump and it can be argued that this release can be part of the formality of when we decide to make a 1.1.x branch, i.e. the community makes a decision/vote that at a certain point in time we are going to bump the minor version which requires a vote and that some vote is also used for the M0 release. In fact, now that I think/write about it, we really should have a formal vote when we make a minor version bump because it is a significant change, it shouldn't be done at whim (even if its from a PMC) > When I say LTS, I mean what versions will get patches for a long time. Java releases are a good example. If an org really needs a Java 22 feature they can use Java 22 in production - but they are expected to upgrade to Java 23, etc. when those versions are released until a new Java LTS is released. There are other OSS equivalents. I am not talking about Commercial Support contracts - commercial entities are very welcome to fill this gap - this does not need to relate directly to the FOSS releases from the ASF project team. I understand the difference between LTS and commercial contract, it's just that even the variables for how long the support is, is something that I don't think we have any ability to estimate concretely now. In summary, in my view it's too soon to even be discussing this. > If the consensus is to delay Pekko 1.1 until every candidate change is made - then fine - but this stops users from using features that are ready to try, like the Netty 4 support. As discussed on the github issue[1], this is a non issue. A milestone release will cater to anyone who really needs netty4 and as stated, it's just as tested as any other Pekko release is. If people are really desperate for netty4, then they can use the milestone (I would also note that I haven't seen any indication that anyone is begging for netty4 right now). > Since Pekko 1.1.0 full release seems like a long way away, it might be worth considering mechanisms to release the most useful changes earlier - in a way that Pekko 1.0 users can uptake. This is what milestones are for, i.e. they are precisely the mechanism to solve this issue. It also solves a host of other issues as discussed here[2]. [1] https://github.com/apache/incubator-pekko/pull/778 [2] https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny On Sun, Nov 5, 2023 at 10:57 PM PJ Fanning <fannin...@gmail.com> wrote: > I have no objections to the general list of changes that we need for > 1.1.0. Some of those changes will likely also need backporting for > 1.0.x releases. > > A 1.1.0-M1 release makes sense. I want to delay it by a week or 2 > while we decide what to do about the config logging (recent Akka CVE). > > I don't think a 1.1.0-M0 is warranted. This git tag has code that is > very similar to Pekko 1.0.1. I don't see the merit in having multiple > ASF contributors having to review such a release. > > I guess it is a separate conversation but there is a fair degree of > resistance to us dropping support for anything. I think we will need > to only drop support if it really makes things much easier for us. > Multi Release Jars seems like a better option than dropping Java 8 > support (for instance). > > When I say LTS, I mean what versions will get patches for a long time. > Java releases are a good example. If an org really needs a Java 22 > feature they can use Java 22 in production - but they are expected to > upgrade to Java 23, etc. when those versions are released until a new > Java LTS is released. There are other OSS equivalents. I am not > talking about Commercial Support contracts - commercial entities are > very welcome to fill this gap - this does not need to relate directly > to the FOSS releases from the ASF project team. > > If the consensus is to delay Pekko 1.1 until every candidate change is > made - then fine - but this stops users from using features that are > ready to try, like the Netty 4 support. > > Since Pekko 1.1.0 full release seems like a long way away, it might be > worth considering mechanisms to release the most useful changes > earlier - in a way that Pekko 1.0 users can uptake. > > > On Sun, 5 Nov 2023 at 12:59, Matthew de Detrich > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > So my take on this > > > > - We should do milestones to solve the general problem you are alluding > to, > > i.e. the M1 milestone that you suggest that we vote on (we should also do > > the M0 milestone which is at the exact moment when a new bump to minor > > version is done, reasoning why is given in this thread[1]). I would argue > > that doing an M1 now is a good idea and then an M2 once other critical > > features land (such as inliner which is mentioned in the below point) > > - There are some critical features that need to be merged before a > release > > of 1.1.0 Pekko Core is ever made (and 1.1.0 Pekko core needs to be > released > > before any other 1.1.0 releases for the other modules) due to technical > > reasons. On the top of my head the critical features so far are the > > inliner[2] and rolling update migration of Akka to Pekko clusters[3]. I > > think it's achievable to get [2] and [3] done in a few months time, but > we > > would have to focus on getting it over the line ([2] is already "done", > it > > just needs a review and testing in downstream modules, [3] likely needs > > more work and most of all testing so that it works as expected). > > - Regarding LTS, I don't think we should entertain the idea now. We have > no > > idea of what and how an LTS can work and we don't even have the capacity > > for it. It might even be a thing that LTS's are "someone else's" problem > > (Pekko is open source after all). I think the most critical thing is > > sticking to semantic versioning, such an expectation is manageable for us > > and I would argue is kind of a requirement for large open source projects > > like Pekko > > - Fixing the manager name [4] should also be fixed for 1.1.0 (actually if > > anything this should be fixed for 1.0.x branch as well) > > - As kind of a stretch goal, sbt-multi-release-jar support for 1.1.0[5] > > would be awesome as it would unblock a **lot** of things while also > keeping > > part of the community happy > > - Releasing pekko 1.1.0 with the latest sbt-osgi (which apparently fixes > a > > lot of pain points versus the current osgi used in Pekko 1.0.x) would be > > another nice stretch goal, currently there is one issue with duplicate > > classes but we now have infrastructure set up[6] so that we can properly > > test such changes. > > > > Note that a lot of the underlying reasoning behind my points are also > > strategic, i.e. keeping features which can be considered critical to > Pekko > > and/or current Akka users which don't require to much effort (basically > > anything that gives a reason for people to use/migrate to Pekko while not > > breaking the i.e. our bank so to speak). I know that there has been a > push > > to do things like drop JDK 8, Scala 2.12, osgi etc etc due to death by a > > thousand cuts but tbh objectively speaking these issues are not taking up > > that much time (at least personally by far the largest amount of time > spent > > is just overhead of having to do so many releases and validate them, > really > > looking forward to the day when we can automate everything with > > sbt-reproducible-builds/jardiff/create jars in ci etc etc). Pekko 2.0.x > > series is when we can look forward to drop a lot of this "annoying > > maintenance" stuff and I would actually strongly argue that at the time > > when we start looking at Pekko 2.0.x we actually get a better idea of > what > > our Pekko users look like, because as has been shown due to the chaos > > created from the license change very few us had any somewhat realistic > lens > > as to how the Pekko community (specifically users) look like, i.e. while > > the OS would **LOVE** to get rid of JDK 1.8 support it just so happens > that > > a lot of people still need to use JDK 1.8 and even though there are > reasons > > to move away from 1.8 evidently they aren't relevant. > > > > [1] https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny > > [2] https://github.com/apache/incubator-pekko/pull/305 > > [3] https://github.com/apache/incubator-pekko/pull/765 > > [4] https://github.com/apache/incubator-pekko/pull/587 > > [5] https://github.com/sbt/sbt-multi-release-jar/issues/22 > > [6] https://github.com/apache/incubator-pekko/issues/75 > > > > On Sun, Nov 5, 2023 at 12:12 PM PJ Fanning <fannin...@apache.org> wrote: > > > > > The core pekko repo [1] has quite a few changes in its main branch that > > > are are targeted at a future 1.1.0 release. > > > > > > We haven't really agreed on what to do with the code that was already > > > deprecated in the Akka era and there is also the issue of the > ApiMayChange > > > annotations on some of the APIs. > > > > > > There are also some new features that developers want to add. > > > > > > We don't have a great deal of developer effort available to us. > > > > > > I suspect that we need to need to balance the need to release some of > the > > > 1.1 changes and then maybe try to make another batch of changes in > Pekko > > > 1.2. > > > > > > What if we aimed to do a Pekko 1.1.0 release in a few months and said > that > > > it was not a Long Term Support release? If we go down this line, we > would > > > probably want to have a tentative plan as to when a new LTS release > would > > > happen. > > > > > > An example of something that would be useful to release would be the > > > netty4 support. I know that the Apache Flink team would like to use > this. > > > > > > Alternatively, we could do a Pekko 1.1.0-M1 release. I suspect that we > > > would end up with a fair number of these and the M version number would > > > discourage uptake (except for testing). > > > > > > What are people's thoughts on the options? > > > > > > > > > > > > [1] https://github.com/apache/incubator-pekko > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > -- > > > > Matthew de Detrich > > > > *Aiven Deutschland GmbH* > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > Alexanderufer 3-7, 10117 Berlin > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > *m:* +491603708037 > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > For additional commands, e-mail: dev-h...@pekko.apache.org > > -- Matthew de Detrich *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Alexanderufer 3-7, 10117 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* matthew.dedetr...@aiven.io
