Re: [all] Release tags, was VOTE Release FileUpload 1.1.1-RC1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Release tags, was VOTE Release FileUpload 1.1.1-RC1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Release tags, was VOTE Release FileUpload 1.1.1-RC1
On 6/1/06, robert burrell donkin [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Release tags, was VOTE Release FileUpload 1.1.1-RC1
On 6/1/06, Rahul Akolkar [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Release tags, was VOTE Release FileUpload 1.1.1-RC1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Release tags, was VOTE Release FileUpload 1.1.1-RC1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
