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
