SVN version tags and release info in changelogs

[Brian J. Tarricone]

On Sat, 20 Sep 2008 17:18:37 +0200 Jannis Pohlmann wrote:

> Hey all,
> 
> we still haven't added the 'svn' version tag back to any of the Xfce
> components after the alpha and we also haven't added some kind of
> release hint like '=== 4.5.90 released ===' to the ChangeLogs. I think
> this is bad. The release hints would make it so much easier to locate
> when the last release was made and which changes have been made since
> then. 

Agreed on the easy-to-find label in the changelog, but don't worry
about the svn tag so much.  The svn tag should be re-added by the
module maintainer the next time they change code in trunk.  If the code
in trunk is identical to the tagged non-svn version, then it doesn't
matter if trunk has the svn tag or not (actually, I'd say it's better
that it doesn't, since a user who updates from trunk and installs will
quickly know that they're just getting the same as the most recent
release with no changes.)

> We'll have to update the NEWS files a number of times in the near
> future, so please let's do this properly: Remove the svn tag
> and add a '=== 4.5.x released ===' hint to the ChangeLog before
> tagging/releasing and add the svn tag back afterwards.

Yeah, do it in as few commits as possible so it's all uniform.  But DO
NOT immediately re-add the svn tag afterward.

1.  It's unnecessary, as I've stated above.

2.  If the package needs to be retagged due to a problem, you've just
broken the monotonically-increasing nature of version numbers.  For
example:

* Remove 'svn' tag and bump version to 4.5.90, and tag as
xfce_4_6_alpha.
* 'svn' tag is readded -- version is now 4.5.90svn-r$REV -- this is
GREATER than 4.5.90 by autoconf's rules.
* Crap, package is bad, need to retag.  Remove 'svn' tag.  BOOM,
version number has now decreased.  Boo that.

Sure, it's not a huge deal, but it's actually easier on the release
manager my way, so...

Oh,and on a side note, I recall Stephan being appalled at me for
committing into a tag and trunk simultaneously to fix a problem instead
of deleting and recreating the tag.  I've since seen the light, and
agree with him -- if you need to retag, delete and recreate the tag,
don't commit to the tag to bring it in line with trunk, because the tag
commit will not actually end up being equivalent to the trunk commit,
and both the changelog and svn log get a little weird.  It's easier to
delete and recreate the tag anyway.

	-brian