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
