But SNAPSHOT builds _are_ publicly available on repository.apache.org. Sure they come and go and you cannot rely on their permanence.
Gary On Thu, Aug 30, 2018, 04:50 sebb <seb...@gmail.com> wrote: > SNAPSHOT builds must only be published to Commons developers. > They cannot be published on public download pages. > > Also they may disappear or be replaced at any time. > > Beta builds are subject to a release VOTE, and so can be published in > the usual way. > Once published, they are permanently available. > > On 30 August 2018 at 09:38, Benedikt Ritter <brit...@apache.org> wrote: > > What's the difference to a nightly build being published to the Apache > > Snapshot repo? > > > > Benedikt > > > > Am Mi., 29. Aug. 2018 um 21:51 Uhr schrieb Gary Gregory < > > garydgreg...@gmail.com>: > > > >> We do not have hard rules for betas AFAIK. IMO, only a beta can depend > on > >> another beta, for example see HttpComponents. We should not release a > >> non-beta that depends on a beta. I think breaking BC is to be expected > in > >> an alpha and less so in a beta. Changing package names and coordinates > from > >> one beta to the next seems a bit excessive but I would not object to it. > >> > >> Gary > >> > >> On Wed, Aug 29, 2018, 10:36 Gilles <gil...@harfang.homelinux.org> > wrote: > >> > >> > Hello. > >> > > >> > Do you have an idea of what it would take to automate "beta" > >> > releases? > >> > By this I mean: take a component (at some state) and create > >> > a branch (with all the necessary adaptations) to become an > >> > official release. > >> > > >> > Are "beta" releases subject to the same BC requirements as > >> > "ordinary" ones? Concretely, suppose that several releases > >> > will be necessary: Do they have to change top-level package > >> > name? > >> > > >> > Can a (non-"beta") release (of some component) depend on a > >> > "beta" release (of another component)? Or has the former to > >> > be a "beta" too? > >> > > >> > Rationale: I imagine that uploading to "Maven Central" may > >> > help correcting the misrepresentation of resources available > >> > from this project. > >> > > >> > > >> > Regards, > >> > Gilles > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> > For additional commands, e-mail: dev-h...@commons.apache.org > >> > > >> > > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
