On 3/27/08, Phil Steitz <[EMAIL PROTECTED]> wrote: > 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: > > > > <snip/> > > > > > > > > IMO, its not a bad idea to get folks to use an alternate repo for > > > > testing RCs, it causes an increased level of awareness :-) > > > > <snap/>
There was a relevant additional post beyond this, but I will clarify that it isn't one repo for all releases, its one repo per final RC i.e. one per set of bits that go up for a vote. This is none different than posting bits in ~s, which are one per vote repos. > > > > > > > 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. > > <snip/> It is not a shared repository. It is a temporary / staging repository so folks can look at the exact bits that will hit the m2 central repo and its mirrors. This staging repo has the following brief lifecycle: * Creation (when bits are "staged" ... i.e. 'mvn -Prc deploy') * Examination (by those who intend to vote on these set of bits) * Sync (moving to rsync repo if vote passes, use stage plugin here) * Deletion (served its purpose in life, nuke it) Note this is the way m2 releases are done in many other projects, its not a new proposal. As suggested initially, the URL of this temporary repo will be, for example, http://pao/builds/commons/scxml/0.8/rc1 (clearly says rc) instead of: http://pao/~rahul/commons/scxml/0.8/rc1 (which is at RM's discretion, may not even mention rc) > > 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. > <snap/> Sure makes it easy to stage releases (see above on one repo per final RC, not one snapshot repo for all RCs). -Rahul > > Phil > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
