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
