On Fri, Oct 3, 2008 at 7:06 AM, Nicholas Bastin firstname.lastname@example.org wrote:
On Thu, Oct 2, 2008 at 4:25 PM, "Martin v. Löwis" email@example.com wrote:
You always create a branch for the release (subversion doesn't make any distinction between a tag and a branch anyhow, so you might as well just make a branch).
I don't think the tag should be edited (there are a few that were, and that's unfortunate already). For example, conversion to bzr will conclude it's a bazaar branch, not a tag.
I agree, that's why I think we should make a branch. Tags should be treated as immutable - it's merely an artifact of a limitation in the source control system we use that you can't make real labels.
It's standard procedure to change the code after declaring it releasable; during the release process, the version numbers get adjusted throughout, and those changes get committed before the release tag is made.
I guess my question is, is there a normal use case where the code needs to be changed for a release after the 'tag' is made? If all the changes are getting committed before the release tag is made, then what is the problem?
It's happened a couple of times when I've made releases - the process I had was to automate it as much as possible, then take the generated tarball, unpack it freshly and run the full tests, and then check things like the README and all those other places. Making a release is still a pretty fiddly process, and things slip through.