> Nobody is threatening to delete our recent snapshots. There is a question about what to do about older snapshots - which is separate from this topic.
I am not saying that people will be deleting our snapshots, but rather there is a current problem with them being pruned (or more correctly not being pruned as expected) which needs to be resolved. > Anyone who wants to test the latest pekko 1.1.0 preview can track down versions at The core point is while its possible for users to manually track snapshots and update them as new ones get released/old ones get deleted this is not practical for the use case I mentioned earlier where we want to set the downstream Pekko modules versions to a more frequently built non release version so we can catch regressions and/or make sure that newly merged features work as expected. If we use snapshots for this then we have the overhead of having to manually update snapshots versions when builds break due to snapshots not existing anymore (note that this hasn't been a problem for now because the snapshot pruning is not working correctly which is the problem I was referring to before). Furthermore if developers want to test newly merged features into development/staging/prod systems to see that there aren't regressions, assuming the snapshots are working correctly (which they currently aren't) they can also hit the same issues regarding the snapshots being pruned. At least to me, this is one of the core problems that the milestone concept is intended to solve, snapshots are too frequent/granular and releases/release candidates are too infrequent. On Sun, Aug 6, 2023 at 2:23 PM PJ Fanning <fannin...@apache.org> wrote: > Nobody is threatening to delete our recent snapshots. There is a > question about what to do about older snapshots - which is separate > from this topic. > > Anyone who wants to test the latest pekko 1.1.0 preview can track down > versions at > > > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-actor-typed_2.13/ > > 1.1.0-M0+5-964dcf53-SNAPSHOT is the most recent - but there will be > new snapshots published most nights (any day that has commits to the > main branch). > > On Sun, 6 Aug 2023 at 13:08, Matthew de Detrich > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > The question to ask is, will these artefacts be used by users or > intended > > for their use? i.e. people who are not subscribed to the mailing list or > > not committers or PMC members? If so, then by ASF definition, that > artefact > > is a release and needs to be voted on by the PPMC/IPMC. > > > > No they aren't, as I said they are treated in the exact same way > snapshots > > are currently treated. The **ONLY** difference is that they will be > > distributed to the Apache Nexus main repository and this is mainly due to > > technical reasons stated before (i.e. snapshots are semi-permanent since > > they need to be pruned). > > > > The primary motivation for the milestone artifacts are > > > > * Internal testing between the Pekko dependencies (i.e. publishing an > > artifact of Pekko core and using that artifact in in other Pekko modules > to > > catch regressions before a release is marked) > > * For Pekko developers to have the ability to test their features which > > were merged into main in their production systems without having to > > manually build Pekko (and possibly all of Pekko's dependencies) > themselves, > > which also as stated previously is quite difficult > > > > There is no intention of the milestones having any formal release > > announcement. > > > > > Have other incubating projects made non-ASF releases while in > incubation? > > In a small number of cases, yes, mostly while they were getting their > code > > base in order but not after they had made an ASF release, and there we > very > > clearly labelled as non-ASF releases. > > > > Yes and this is not meant to be a formal ASF release, hence the previous > > suggestion of making this clear even in the DISCLAIMER file > > > > > Re official documentation/process that describes this distinction? Yes, > > that policy page sets that out. See, for instance [1] and [2] for why it > > needs to be this way. > > > > [1] Is talking about source packages, this discussion is about binary > > artifacts. In the last line they mention this > > > > > Nightly Builds that are not release candidates can be hosted at > > ci.apache.org projects area, just file an INFRA ticket. > > > > The links to ci.apache.org aren't even working and I doubt we can even > use > > such a repository since we are dealing with JVM jar's specifically > > > > > Re official documentation/process that describes this distinction? Yes, > > that policy page sets that out. See, for instance [1] and [2] for why it > > needs to be this way. The Incubator distribution guideline also covers > this > > [3]. You see that at [4] "Release candidates, nightlys and snapshots must > > not be advertised to the general public.” and you can read [5] for why. > The > > release distribution policy also touches on this e.g. [6] > > > > As was clarified earlier, milestones are **NOT** releases, they are > treated > > the exact same way as snapshots, nightlies or release candidates with the > > **ONLY** critical difference being that they are deployed in a repository > > that is not snapshots and they are published less frequently then a > > snapshot/nightly is. > > > > With this being said I am increasingly of the opinion that this is more > of > > a technical INFRA question than an ASF policy question since the issues > > being discussed are technical in nature. There was never a suggestion of > > making an alternative formal type of ASF release. > > > > > > > > > > > > > > On Sun, Aug 6, 2023 at 10:51 AM Justin Mclean <jus...@classsoftware.com> > > wrote: > > > > > Hi, > > > > > > The question to ask is, will these artefacts be used by users or > intended > > > for their use? i.e. people who are not subscribed to the mailing list > or > > > not committers or PMC members? If so, then by ASF definition, that > artefact > > > is a release and needs to be voted on by the PPMC/IPMC. > > > > > > Have other incubating projects made non-ASF releases while in > incubation? > > > In a small number of cases, yes, mostly while they were getting their > code > > > base in order but not after they had made an ASF release, and there we > very > > > clearly labelled as non-ASF releases. > > > > > > Re official documentation/process that describes this distinction? Yes, > > > that policy page sets that out. See, for instance [1] and [2] for why > it > > > needs to be this way. The Incubator distribution guideline also covers > this > > > [3]. You see that at [4] "Release candidates, nightlys and snapshots > must > > > not be advertised to the general public.” and you can read [5] for > why. The > > > release distribution policy also touches on this e.g. [6] > > > > > > Kind Regards, > > > Justin > > > > > > 1. https://www.apache.org/legal/release-policy.html#host-rc > > > 2. https://www.apache.org/legal/release-policy.html#why > > > 3. > > > > https://cwiki.apache.org/confluence/display/INCUBATOR/Distribution+Guidelines > > > 4. > https://incubator.apache.org/guides/distribution.html#release_platforms > > > 5. https://incubator.apache.org/guides/distribution.html#motivation > > > 6. https://infra.apache.org/release-distribution.html#maven > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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
