On Wed, Aug 17, 2011 at 7:55 AM, Stephen Connolly <[email protected]> wrote: > That assumes that nobody outside of Apache inherits from these shared poms... > > A scary assumption to make IMHO
I don't see why it has to be scary. First of all, from a legal standpoint, these guys would get covered by votes on things that use them. So the only possible exposure is someone pitching some sort of fit about the state of one of these POMs between running the release plugin and voting on some project that consumes it. Second of all, why is it any more scary than what happens when someone fishes stuff out of svn? > > 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]
