nah, you are right. Especially given that those master-pom releases should have _especially_ good visibility in the community. Because just upgrading to a newer version might give you completely different behaviour!
So I'd say we should stick with the official vote. LieGrue, strub --- On Wed, 8/17/11, Stephen Connolly <[email protected]> wrote: > From: Stephen Connolly <[email protected]> > Subject: Re: Must a pom release be an ASF release? > To: "Maven Developers List" <[email protected]> > Date: Wednesday, August 17, 2011, 11:57 AM > I take the simple view that if it > ends up in > https://repository.apache.org/content/repositories/releases/ > then it > is a release therefore the release voting rules apply... > But I am > willing to accept if the majority want to put a different > criteria on > what constitutes a release > > On 17 August 2011 12:55, Stephen Connolly > <[email protected]> > wrote: > > That assumes that nobody outside of Apache inherits > from these shared poms... > > > > A scary assumption to make IMHO > > > > On 17 August 2011 12:50, Benson Margulies <[email protected]> > wrote: > >> This tees off of a remark in the recent vote > thread about the > >> disruption to CI of pom releases. > >> > >> I don't believe that we need the full ASF release > voting process for > >> our internal shared POMs. > >> > >> I reason as follows: > >> > >> The Apache release process creates a particular > legal status for a > >> body of code. This has certain advantages for > users and developers. > >> > >> However, that assumes that there are users! > However, these POMs are > >> not intended for use by anything except other > pieces of Maven (the > >> global ASF pom might be an exception). Thus, they > should be viewed as > >> part of the releases of Maven itself and the > components and plugins, > >> not as independent releases. > >> > >> To build any of our user-visible components from > source, you need to > >> use the right parent POM (give our take our friend > at Gentoo). > >> Arguably, what we need here is a tweak to the > source plugin, or some > >> other plugin, that could sweep the chain of > parents into 'the > >> release', or at least enumerate them. We could > then argue that, > >> maven-release-plugin aside, the shared poms are > formally 'released' > >> when the components that use them are releases. > >> > >> If this argument holds water, the shared poms > could be pushed via the > >> maven-release-plugin via lazy consensus, and the > CI problems go away. > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
