On Thu, Mar 27, 2008 at 4:33 AM, sebb <[EMAIL PROTECTED]> wrote: > > On 27/03/2008, Phil Steitz <[EMAIL PROTECTED]> wrote: > > On Sat, Mar 22, 2008 at 9:23 PM, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > > > > > On 3/22/08, Phil Steitz <[EMAIL PROTECTED]> wrote: > > > > On Sat, Mar 22, 2008 at 6:16 PM, Wendy Smoak <[EMAIL PROTECTED]> > wrote: > > > > > On Sat, Mar 22, 2008 at 3:10 PM, Phil Steitz <[EMAIL PROTECTED]> > wrote: > > > > > > > > > > > 3) Announce availability of RC, publish RC-labeled jar to > snapshot > > > > > > repo and tarballs to ~psteitz > > > > > > > > > > In order for (5) to be automated with the stage plugin, you > would need > > > > > to stage each release in a separate repository. I think that's > > > > > already taken care of with the proposed changes to the parent pom > > > > > using space under people.a.o/builds/. > > > > > > > > > > (Non-snapshot artifacts shouldn't go in the snapshot repository, > > > > > though I'm probably responsible for starting that practice over > at > > > > > Struts a long time ago.) > > > > > > > > > > > > > I don't see why it should be "illegal" to publish an RC to the > > > > snapshot repo. We do not distinguish "stable", "ga", "beta" etc > here > > > > in Commons. We have releases and things that are not yet released. > I > > > > don't see why we need yet another repo for RCs. We - at least I - > > > > like for people to test with our RCs *before* we vote on them. So > > > > maybe its just semantics and I am calling the RCs (with "RC" in the > > > > artifact name) "snapshots." I don't see the need to ask people to > > > > configure yet another special repo to test our RCs. > > > > > > > <snip/> > > > > > > For the style of RCs you've described, there is nothing against > > > putting them in the m2-snap-repo. But the final RC that you describe > > > is best not placed there, because: > > > > > > * Fundamentally, its a (soon-to-be) release, not a snap > > > * Wendy is alluding to a limitation of the stage plugin that requires > > > the staging repo to be clean (it will currently copy all versions that > > > exist in the staging repo over to the rsync repo! -- obviously that > > > means you don't want the m2-snap-repo to also be the staging repo > > > ATM). And for folks like me who won't be correcting metadata files by > > > hand (tedious, open to operator error), the stage plugin is needed. > > > > > > IMO, its not a bad idea to get folks to use an alternate repo for > > > testing RCs, it causes an increased level of awareness :-) > > > > > > > It should be obvious that code uploaded to a personal user directory > has not been formally released. > > If a shared repository is used then this is less obvious, and there is > a risk that users will assume that it is a release. If a shared > repository is to be used for unreleased (development) code then it > needs to be very clearly identified as such, and the repository > location should not be published to users. > This is why I put the RCs (without final release names) for testing in the snapshot repo, which is presented as a "development repo" and understood by the community to hold development snapshots for integration testing. I am OK developing another snapshot repo for RCs, but personally don't really get the need for it, other than to make it easier to stage releases.
Phil > > > > As long as there is a simple way for developers to test the RCs, I > > will be happy. I also do not like editing the metadata files, so if we > > can get the staging stuff to really work for the final release with no > > fear of badness or violating the tag <-> artifact binding, I will be > > happier still. Thanks! > > > > > > Phil > > > > > > > > ------------------------------------------------------------- > > > 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]
