You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2006/05/29 13:35:19 UTC

Re: [all] Release tags, was VOTE Release FileUpload 1.1.1-RC1

Simon Kitching wrote:
> On Sun, 2006-05-28 at 00:03 -0700, Henri Yandell wrote:
>>[I haven't created an SVN tag for the RC1. Is there any particular
>>reason the release info says to create a tag?]
> Making a tag in subversion has exactly the same price as checking in one
> new file, ie is trivial. I think the existing release advice is
> therefore good; creating a tag for an RC should be the regular
> practice. 

Personally I don't like the resulting 'tag clutter'. Is there any way in 
SVN to remove dead tags?

Stephen

---------------------------------------------------------------------
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


Re: [all] Release tags, was VOTE Release FileUpload 1.1.1-RC1

Posted by Henri Yandell <fl...@gmail.com>.
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 robert burrell donkin <ro...@blueyonder.co.uk>.
On Mon, 2006-05-29 at 23:43 +1200, Simon Kitching wrote:
> On Mon, 2006-05-29 at 12:35 +0100, Stephen Colebourne wrote:
> > Simon Kitching wrote:
> > > On Sun, 2006-05-28 at 00:03 -0700, Henri Yandell wrote:
> > >>[I haven't created an SVN tag for the RC1. Is there any particular
> > >>reason the release info says to create a tag?]
> > > Making a tag in subversion has exactly the same price as checking in one
> > > new file, ie is trivial. I think the existing release advice is
> > > therefore good; creating a tag for an RC should be the regular
> > > practice. 
> > 
> > Personally I don't like the resulting 'tag clutter'. Is there any way in 
> > SVN to remove dead tags?
> 
> Sure; "svn rm". A tag is just a directory (well, actually, just an entry
> in the parent directory that points to a specific "inode").
> 
> For RCs from releases before the current one, I think deleting them
> seems reasonable (eg when 1.2 is released, remove 1.0 RC tags). I'd
> prefer to keep RC tags for at least one release though. If you don't
> like them in the main "tags" directory, they could be pushed down into a
> special "RC" directory....
> 
> Of course "delete" just makes them not visible in the head revision; the
> "tag" directory is still there if you look for it.

is there any reason why we actually need to remove dead tags?

subversion holds the history of the project and deleting history seems a
little extreme (as well as bring potentially problems down the line).
why not just move dead tags to a special area?

- 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 Simon Kitching <sk...@apache.org>.
On Mon, 2006-05-29 at 12:35 +0100, Stephen Colebourne wrote:
> Simon Kitching wrote:
> > On Sun, 2006-05-28 at 00:03 -0700, Henri Yandell wrote:
> >>[I haven't created an SVN tag for the RC1. Is there any particular
> >>reason the release info says to create a tag?]
> > Making a tag in subversion has exactly the same price as checking in one
> > new file, ie is trivial. I think the existing release advice is
> > therefore good; creating a tag for an RC should be the regular
> > practice. 
> 
> Personally I don't like the resulting 'tag clutter'. Is there any way in 
> SVN to remove dead tags?

Sure; "svn rm". A tag is just a directory (well, actually, just an entry
in the parent directory that points to a specific "inode").

For RCs from releases before the current one, I think deleting them
seems reasonable (eg when 1.2 is released, remove 1.0 RC tags). I'd
prefer to keep RC tags for at least one release though. If you don't
like them in the main "tags" directory, they could be pushed down into a
special "RC" directory....

Of course "delete" just makes them not visible in the head revision; the
"tag" directory is still there if you look for it.

Cheers,

Simon



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