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: [all] Release tags, was VOTE Release FileUpload 1.1.1-RC1
Date Thu, 01 Jun 2006 20:22:53 GMT
On 6/1/06, robert burrell donkin <robertburrelldonkin@blueyonder.co.uk> wrote:
> On Thu, 2006-06-01 at 19:05 +0100, Stephen Colebourne wrote:
> > Henri Yandell wrote:
> > > I pondered it for a while. The tag is of value - it's so we can start
> > > a branch if trunk suddenly becomes untenable. My biggest concern with
> > > Simon's reason was that it encourages read-write tags if we take it
> > > fully.
> > >
> > > Ideally we would copy the rc tag to the release tag, modify the rc
> > > bits to the real release and then build a release. Are we happy with
> > > tags being edited like that?
>
> not really: makes it a lot more difficult to work out what the release
> was actually cut from
>
<snip/>

Agreed, best to have tags read only.


> > Well I know I'd have to rethink all the scripts I've now worked up to
> > get releases out consistently and easily.
> >
> > Sounds like all we might agree on here is for each release manager to
> > make a choice.
>
> i'm unhappy about tags being deleted and i don't really think it's
> necessary with subversion.
>
<snap/>

Same here.


> why not separate releases from release candidates?
>
> for example:
>
> commons-whatever ----- trunk
>                                  |
>                                  - branches
>                                  |
>                                  - tags
>                                  |
>                                  - candidates
>                                  |
>                                  - releases
>
> - robert
>
<snip/>

The purpose being trying to avoid tag clutter in the tags directory?
Lets stick to a tag naming convention and let the sleeping dogs die?

-Rahul

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


Mime
View raw message