You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2006/06/01 07:38:30 UTC
Re: [all] Release tags, was VOTE Release FileUpload 1.1.1-RC1
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?
As long as we keep a nice naming scheme, I dont think they clutter
things too much. I'm more irritated when I try to look at the tags for
something like Modeler, lots of different types of tag scheme.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Release tags, was VOTE Release FileUpload 1.1.1-RC1
Posted by Rahul Akolkar <ra...@gmail.com>.
On 6/1/06, Rahul Akolkar <ra...@gmail.com> wrote:
<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?
>
<snap/>
And s/die/lie/ as well ;-)
-Rahul
> -Rahul
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Release tags, was VOTE Release FileUpload 1.1.1-RC1
Posted by Rahul Akolkar <ra...@gmail.com>.
On 6/1/06, robert burrell donkin <ro...@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
Re: [all] Release tags, was VOTE Release FileUpload 1.1.1-RC1
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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
> 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.
why not separate releases from release candidates?
for example:
commons-whatever ----- trunk
|
- branches
|
- tags
|
- candidates
|
- releases
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Release tags, was VOTE Release FileUpload 1.1.1-RC1
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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?
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.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org