commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [m2][PROPOSAL] Release process
Date Thu, 27 Mar 2008 18:02:28 GMT
On 3/27/08, Phil Steitz <phil.steitz@gmail.com> wrote:
> On Thu, Mar 27, 2008 at 4:33 AM, sebb <sebbaz@gmail.com> wrote:
>  >
>
> > On 27/03/2008, Phil Steitz <phil.steitz@gmail.com> wrote:
>  >  > On Sat, Mar 22, 2008 at 9:23 PM, Rahul Akolkar <rahul.akolkar@gmail.com>
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message