[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: [all] m2 releases, common issues
From:       "Rahul Akolkar" <rahul.akolkar () gmail ! com>
Date:       2008-05-30 21:33:24
Message-ID: ce1f2ea80805301433o78817fb6i5cde32f73ea08ad5 () mail ! gmail ! com
[Download RAW message or body]

On 5/30/08, sebb <sebbaz@gmail.com> wrote:
> On 30/05/2008, Luc Maisonobe <Luc.Maisonobe@free.fr> wrote:
>  > Dennis Lundberg a écrit :
>  >
>  > > Niall Pemberton wrote:
>  >  >> On Wed, May 28, 2008 at 10:35 PM, Dennis Lundberg <dennisl@apache.org>
>  >  >> wrote:
>  >  >>> Rahul Akolkar wrote:
<snip/>
>  >  >>>>
>  >  >>>> 4) Release plugin will rewrite the SCM URLs. I used one approach (of
>  >  >>>> using the RC tag here), but not everyone liked it.
>  >  >>> This is by design. How is this a problem for us? Is it a problem for
>  >  >>> RCs?
>  >  >>
>  >  >> Pointing to the RC tag, rather than final tag for the release - e.g.
>  >  >> scxml 0.8
>  >  >> http://repo1.maven.org/maven2/commons-scxml/commons-scxml/0.8/commons-scxml-0.8.pom
>  >  >>
>  >  >
>  >  > Ah, I see. That's because the way we currently do releases isn't
>  >  > directly supported by the release plugin.
>  >  >
>  >  > So we either change the way we do releases. Instead of voting on stuff
>  >  > with an RC-tag in svn we'd vote on stuff with a release-tag. If the
>  >  > release faila the release tag is removed and is later recreated when all
>  >  > problems have been solved. If someone wants to have a special RC-tag,
>  >  > for the sake of history, that can be accomplished easily with a command
>  >  > line subversion remote copy. If we wanted to, we could turn that into a
>  >  > Maven plugin and attach it to the release cycle.
>  >
>  >
>  > I don't really like this idea. All our discussions are public and the
>  >  staging repository is publicly available. This means versions with the
>  >  proper tag and proper signatures are available for download by anybody.
>  >  If someone grabs one such version and the vote fails, we will end up
>  >  with two different versions with the same tags, different contents and
>  >  good signatures. I'm sure this will lead to confusion one day.
>  >
>
>
> Voting would also need to include the revision number - probably not a
>  bad idea anyway, as tags are sometimes recreated.
>
<snap/>

The style I've used never touches a tag after it is created, and I
intend to continue doing releases this way until a better option shows
up. If tags are sometimes recreated etc., sure, that diminishes their
intrinsic value and additional precautions may be necessary.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]