+1 for this, IIRC Matthew suggested this kind of release too. 何品
Matthew de Detrich <[email protected]> 于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 < > [email protected]> 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 <[email protected]> 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 > >> <[email protected]> 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 <[email protected]> > >> 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: [email protected] > >> > > For additional commands, e-mail: [email protected] > >> > > > >> > > > >> > > >> > -- > >> > > >> > 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:* [email protected] > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > -- > > > > 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:* [email protected] > > > > > -- > > 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:* [email protected] >
