Regarding mult-release JAR support, I did some initial work[1] and I think that this will have to wait, possible for SBT 2.x since there are fundamental limitations in sbt to properly support this.
Note that its still technically possible, but in doing so we have to statically define a set of keys (i.e. SBT SettingKey) for **every** JDK version that we want to build and since we are already at JDK 21 this can get unwieldy pretty quickly. [1] https://github.com/sbt/sbt-multi-release-jar/issues/24#issuecomment-1891156070 On Wed, Jan 10, 2024 at 11:06 AM Matthew de Detrich < matthew.dedetr...@aiven.io> wrote: > So I have some good news for one of the big ticket items listed earlier, > Pekko is now using the latest version of sbt-osgi which contains a lot of > fixes and > improvements, see https://github.com/apache/incubator-pekko/pull/920. > This avoids > us having to drop sbt-osgi support (doing so is not off the table > completely but should > be made as a community decision later). Also > https://github.com/apache/incubator-pekko/pull/252 > landed which is important since it's a behavioural change. > > I would say the only other big item that should be handled before an M1 > vote is > finishing off the inliner changes, > https://github.com/apache/incubator-pekko/pull/587 > and the migration of akka to pekko clusters. A milestone release of these > changes > will provide ample opportunity for extensive testing to make sure as much > as possible > that the full release is without issues. I left out multi-release-jar > support, my feeling is > that this is too big of a change for M1 but It might make sense as an M2 > or as part of 1.2.x. > > If there is anything that's left out please mention it. > > On Sun, Dec 24, 2023 at 7:42 AM kerr <hepin1...@gmail.com> wrote: > >> +1 for this, IIRC Matthew suggested this kind of release too. >> 何品 >> >> >> Matthew de Detrich <matthew.dedetr...@aiven.io.invalid> 于2023年12月13日周三 >> 07:06写道： >> >> > Apologies for necroing this topic, but there is one other feature I >> would >> > like to add to the M1 >> > milestone release which is >> > https://github.com/apache/incubator-pekko/pull/252. The reason I >> > am pointing out this issue specifically is that it is a breaking >> behaviour >> > change (all of the >> > details are in the PR) so it needs to land for the 1.1.x series, ideally >> > for M1 so we can figure >> > out if there are any behavioural regressions. >> > >> > On Mon, Nov 6, 2023 at 8:40 PM Matthew de Detrich < >> > matthew.dedetr...@aiven.io> wrote: >> > >> > > > 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 >> > > >> > >> > >> > -- >> > >> > 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 >> > >> > > > -- > > 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 > -- 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
