Maybe I'm missing something, but why you cannot checkin the upgrade to the non-yet-released parent? Ok, our ITs would be broken, but else?
Devs of course should test the new parent upgrade anyway, so the build is not accidentally 'broken'. 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, 3:05 PM > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
