staging repos are always visible to the public also (if they know the URL).
I for one have a -Pstaging profile in my settings.xml which I (re-)use for that kind of stuff. Cheap enough... 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, 4:39 PM > On Wed, Aug 17, 2011 at 11:51 AM, > Stephen Connolly > <[email protected]> > wrote: > > Well look all we need to do is say that for pom > releases the vote can > > be as short as getting 3 binding +1's and it can be > guillotined once > > those three binding +1's have been cast. That could > give you the > > release in short time. In any case you cannot commit > to the next > > release version without fear of breakage until you > have confirmed that > > the pom has been pushed to central, which is every 8 > hours IIRC > > Unless we made use of a 'mirror trick'? I'm not sure that > the > following hangs together. What if there was a repo group > for us at > repository.apache.org that aggregated the staging repos for > a flock of > pom changes, and maven developers knew where to find a > settings.xml > with a mirror-of-* (to avoid adding <repository> > elements to poms) > that searched it in place of central? Then a releaser of > the flock > could stage the first, commit to it, stage the second ..., > and then > call a vote. (Except that this would require 'open' staging > repos to > be visible, which I fear that they are not?) > > > > > > On 17 August 2011 16:28, Benson Margulies <[email protected]> > wrote: > >> 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] > >> > >> > > > > > --------------------------------------------------------------------- > > 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]
