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
