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
