> Doing binary M0/M1 releases to Maven Central without a proper vote would not be allowed under my understanding but it can be raised with the Incubator PMC.
I will ask in general incubator chat then > Even if they agree it's ok, I would still favour not doing so. I think there is some merit in releasing preview milestones but to do so with the normal release process. To me at least milestones sit somewhere between a snapshot and a full release. I don't think milestones requiring a vote adds any real value, after all the whole point of the milestone is that these changes are not voted/released but they have been technically approved to be in main. Actually the point in adding a section in the DISCLAIMER for a milestone release is to point that out. > Changing our DISCLAIMER to WIP version would be a major issue when we get around to trying to become a TLP. I am not sure if WIP is the write kind of note to the DISCLAIMER (this will be clarified later) but to be clear, whether its WIP or something else, that note would only be for that specific milestone release. The intention is not for the pekko modules to jump between 2 states (i.e. WIP and not WIP). > In the end, Pekko's biggest problem is that we don't really have an active PPMC. Email threads on the private mailing list about adding new committers are being ignored and that leaves us in a major Catch 22 scenario about growing the PPMC. Without a much larger number of active PPMC members, I don't see how we can manage multiple versions of Pekko or add extra repos. I agree and I think there are various reasons for this. My personal observational summary for this is that the Apache process is both foreign to a lot of our PPMC and perceived to be very bureaucratic/overbearing. My suggestion of having milestone releases without a formal vote is designed to be a practical/pragmatic solution to this issue, I mean if we end up making releases around once a month than that would be fantastic but we don't have the capacity for this. I am doing my best to at least automatic most of the manual overhead (i.e. the recent inclusion of sbt-reproducible-builds is an example of this, there is a lot more low hanging fruit that can be done here) but that can only do so much. On Sat, Aug 5, 2023 at 1:24 PM PJ Fanning <fannin...@gmail.com> wrote: > Doing binary M0/M1 releases to Maven Central without a proper vote > would not be allowed under my understanding but it can be raised with > the Incubator PMC. > > Even if they agree it's ok, I would still favour not doing so. I think > there is some merit in releasing preview milestones but to do so with > the normal release process. > > Changing our DISCLAIMER to WIP version would be a major issue when we > get around to trying to become a TLP. > > In the end, Pekko's biggest problem is that we don't really have an > active PPMC. Email threads on the private mailing list about adding > new committers are being ignored and that leaves us in a major Catch > 22 scenario about growing the PPMC. Without a much larger number of > active PPMC members, I don't see how we can manage multiple versions > of Pekko or add extra repos. > > On Sat, 5 Aug 2023 at 12:03, Matthew de Detrich > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > 1. A release to Maven Central - this will require a full release of > > source distribution and 2 phase vote on the RCs - like a full release > > > > Is there a way to get around the voting by adding a note in the > DISCLAIMER > > file? > > We can automate this quite easily (i.e. we can modify > > the apacheSonatypeDisclaimerFile > > sbt setting to do something different if version contains -M(\d+) ) > > > > In general the style of publishing milestones to Maven on a > > semi-frequent basis > > is what the Scala OS community is most familiar with and I would say if > we > > are forced to do an entire full vote it (almost) defeats the purpose of a > > milestone > > (you may as well do a release then) > > > > > Johannes Rudolph has suggested that we don't automatically release > > downstream modules when we release Pekko minor releases. > > > > Agreed, but what I was suggesting is to just bump the pekko version in a > > downstream pekko module to the milestone that was just released so that > > at least the CI for that pekko module can catch it (and in turn when the > > milestone for that said pekko module is released then people can > > transitively check both milestone releases). > > > > > For Pekko > > HTTP 1.0.x could continue to be our only release line for Pekko HTTP > > and we test that it works Pekko 1.0.x and Pekko 1.1.y. This approach > > reduces the overall overhead of a Pekko 1.1.0 release. It is not > > insignificant either because we need to go through all our other repos > > and ensure that the code in them at least works with Pekko 1.1.0. This > > a lot of work but not as much as having to push through a multi-month > > release cycle with 2 phase voting on a dozen or more extra RCs. > > > > I am not advocating to automatically make a release when a new Pekko > > patch release is made, just that we transitively update the milestones to > > the > > dependencies. The release cycle would be unaffected by these version > > bumps, it's just that when we do make a release we will just use the > latest > > version for that pekko dependency > > > > Also note that this entire step of setting the milestone versions > > in downstream modules can be almost completely automated > > with scala-steward, i.e. it will detect when a new milestone > > is released and automatically creates a PR for it while running all of > the > > CI tests. > > > > > Then when we have a Pekko 1.1.0 release, there will be pressure to do > > a Pekko 1.2.0 release and we then end up having to test that every > > repo works with 3 versions of Pekko (1.0.x, 1.1.y, 1.2.z). > > > > This is a concern but I think also somewhat unrelated to this point. Not > > dismissing this, definitely needs to be talked about just separately > > although > > it is to be noted that my milestone+auto bump suggestion with scala > steward > > does help in reducing the risk of not noticing regressions. > > > > On Sat, Aug 5, 2023 at 12:45 PM PJ Fanning <fannin...@apache.org> wrote: > > > > > The idea of having milestone binary releases may be attractive but we > > > need to agree what a milestone release is. > > > > > > 1. A release to Maven Central - this will require a full release of > > > source distribution and 2 phase vote on the RCs - like a full release > > > 2. Binaries that we push to nightlies.apache.org - INFRA have > > > expressed a preference that we post non-release jars that we want to > > > have reasonably long or indefinite availability to > > > nightlies.apache.org (an Rsync site) > > > 3. Post the binaries as milestones as snapshots to > > > repository.apache.org but live with the fact that INFRA team do not > > > want us to leave the snapshot jars on repository.apache.org > > > indefinitely > > > 4. Post the binaries as milestones to repository.apache.org release > > > staging area - but this still may not be ok with INFRA team (see 3 > > > above) and we risk having the files released to Maven Central by > > > accident. > > > > > > Johannes Rudolph has suggested that we don't automatically release > > > downstream modules when we release Pekko minor releases. For Pekko > > > HTTP 1.0.x could continue to be our only release line for Pekko HTTP > > > and we test that it works Pekko 1.0.x and Pekko 1.1.y. This approach > > > reduces the overall overhead of a Pekko 1.1.0 release. It is not > > > insignificant either because we need to go through all our other repos > > > and ensure that the code in them at least works with Pekko 1.1.0. This > > > a lot of work but not as much as having to push through a multi-month > > > release cycle with 2 phase voting on a dozen or more extra RCs. > > > > > > Then when we have a Pekko 1.1.0 release, there will be pressure to do > > > a Pekko 1.2.0 release and we then end up having to test that every > > > repo works with 3 versions of Pekko (1.0.x, 1.1.y, 1.2.z). > > > > > > > > > On Sat, 5 Aug 2023 at 11:17, Matthew de Detrich > > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > > > Hello community, > > > > > > > > I want to discuss the option of providing milestone (i.e. version-M1, > > > > version-M2) releases on a semi frequent (top of my head would be > > > > approximately monthly and/or once enough changes get merged into > main but > > > > of course open to discuss) basis. > > > > > > > > The context behind this is it was raised elsewhere[1] that full > releases > > > > are not going to be as frequent as the community expects (I > personally > > > > don't fully agree with this, I think that release cadence can change > over > > > > time especially if more people volunteer as a release manager and/or > > > voting > > > > for releases but that's another debate). Given where we are at now > if we > > > > only expect to have releases at best every half year then I don't > think > > > > it's constructive/practical for users to wait such long periods of > time > > > to > > > > use merged unreleased features in a more serious manner. > > > > > > > > People might raise that nothing needs to be done since we provide > > > snapshots > > > > however we currently have been approached from INFRA that our > snapshot > > > > strategy needs to change, tl;dr is that you shouldn't be expecting > > > > SNAPSHOT's to be available for any significant period of time (hence > the > > > > suggestion for milestones). > > > > > > > > Building locally is of course another option, but given how brittle > it is > > > > to build a proper binary of Pekko (as has been shown before with > mistakes > > > > done during releases). There is also the fact that Pekko is a multi > > > module > > > > project which means that if you want to test changes to one module > that > > > has > > > > to be propagated to other modules you end up having to do manual > > > dependency > > > > management while building locally from source. > > > > > > > > Milestone's provide another big advantage which also means validating > > > > changes that are merged into Pekko don't break downstream Pekko > modules. > > > > With our current strategy we pin the downstrain Pekko modules to the > full > > > > upstream release and this only ever gets updated when a next release > > > occurs > > > > which given what I said earlier would be very infrequent. This > leaves a > > > > large span of time where essentially we don't validate that merged > > > upstream > > > > Pekko changes, meaning that we only figure out potential problems > all at > > > > once when the next release gets initiated. Instead if we pubish > > > > semi-frequent milestones, we can then update Pekko's downstream > modules > > > to > > > > use those milestones as they are released which would let us catch > > > > potential problems sooner. > > > > > > > > There are also some details to consider, i.e. do the milestone's > binaries > > > > need to be signed or not? If we don't care about signing the > milestones, > > > we > > > > can easily publish them from a github action in the same way > snapshots > > > are > > > > but with an automatic trigger (i.e. someone pushes a milestone tag). > This > > > > is by far the least friction approach since releasing a milestone > would > > > > literally be done just by the click of a button, otherwise someone > would > > > > need to build, sign and publish locally, which isn't a huge deal > rather > > > > just a slight annoyance. > > > > > > > > [1] https://lists.apache.org/thread/b57nmyrg5xhgdv3gnbq2o9s6wsqf31q6 > > > > -- > > > > > > > > Matthew de Detrich > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > Immanuelkirchstraße 26, 10405 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 > > > > 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 Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* matthew.dedetr...@aiven.io