I don't see how. If I want to change the plugins parent to refer to a new version of the global maven parent, I can't even check in that change to svn until the new global parent is deployed to a repository. Now, we might imagine using an extra repository for this, I guess ...
On Wed, Aug 17, 2011 at 11:02 AM, Mark Struberg <[email protected]> wrote: > But we can do this all in one go, isn't? > > Just stage the projects locally and call Votes which are depending on each > other. > > LieGrue, > strub > > --- On Wed, 8/17/11, Benson Margulies <[email protected]> wrote: > >> From: Benson Margulies <[email protected]> >> Subject: Re: Must a pom release be an ASF release? >> To: "Maven Developers List" <[email protected]> >> Date: Wednesday, August 17, 2011, 2:56 PM >> On Wed, Aug 17, 2011 at 10:45 AM, >> Brian Fox <[email protected]> >> wrote: >> > Benson, what problem exactly are you trying to solve >> here? >> >> 1) If you want to make a set of coordinated changes up the >> chain of >> poms, it's extremely time-consuming, with a 3-day vote at >> each step. >> >> 2) Our automated builds break during the 3-day window. >> >> >> > >> > On Wed, Aug 17, 2011 at 7:50 AM, 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] >> >> > > --------------------------------------------------------------------- > 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]
