On Wed, Aug 17, 2011 at 11:15 AM, Mark Struberg <[email protected]> wrote: > 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?
Not only the ITs, but the private builds of everyone who does an svn up between the checkin and the promotion. No? > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
