commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [m2][PROPOSAL] Release process
Date Sun, 23 Mar 2008 06:23:31 GMT
>  > 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

Right.  I would not put the to-be-voted-on candidate there, just the
RCs leading up the the final, all of which have "RC" in their version

>   * 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 :-)
I just want to make it as simple as possible for developers to test
our RCs and I think having "RC" in the artifact name is enough to
ensure people know what they are testing.

I want to do everything possible to encourage development community
testing of release candidates. I think we do a good job - maybe even
too good a job - validating structure, formal contents and doing
static code analysis of release packages and I would like to see more
of that energy applied to validating the code itself from a functional


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message