[MERGE] Tagging bzr releases

[Jelmer Vernooij]

On Tue, 2009-02-10 at 13:38 -0600, John Arbash Meinel wrote:
> Jelmer Vernooij wrote:
> > The attached patch updates releasing.txt to mention tagging of the
> > release. 
> We've never had a policy of tagging releases. I've done it ad-hoc in my
> jam-integration branch
> (http://bzr.arbash-meinel.com/branches/bzr/jam-integration).
Hmm, I wonder where I got my tags from then :-)

> There is still something wrong about how PQM manages things, in that the
> tags aren't getting propagated from branches that get merged, into the
> trunk. Though I haven't tried since we upgraded bzr.dev to 1.9 format
> (which also, IIRC, required updating the bzr used by PQM).
> 
> Anyway, I've always used tags of the form:
>   bzr-1.12rc1
> 
> rather than just "1.12rc1".
> 
> Other projects (bzrtools, qbzr) use "release-1.12rc1". bzr-svn seesm to
> use my form: "bzr-svn-0.4.9" (though bzr-svn-0.5.0~rc1).
The reason for the ~ is that 0.5.0~rc1 sorts before 0.5.0 in Debian;
0.5.0rc1 sorts *after* 0.5.0.

> Obviously, I have a preference for "$PROJECT-$VERSION". It isn't strong
> enough, but consistency here would be nice.
I have a preference for "$PROJECT-$VERSION" as well, mainly because it
 works when you have nested trees (merging subvertpy 0.5.0 into bzr-svn
 doesn't create a 0.5.0 tag but a subvertpy-0.5.0 tag). Everybody else
 seems to prefer just $VERSION though, which is why I picked that
 here.

> In the end:
> 
> 1) I'd like to officially tag releases.
> 2) It is a bit tricky, because you really want to create a tag at the
> tip of the branch, which you can't do until after PQM has finished
> committing. And then we don't have a way to inject that tag back into
> the release branch it exists on. We *can* inject that tag into bzr.dev
> when we merge the release back into trunk. 	
> 3) Martin didn't actually get the 1.12rc1 changes submitted (and
> accepted) through PQM, he released from a local branch (I assume). I
> went ahead and applied the changes and submitted them for 1.12rc1
> because I needed them to get the win32 installers built.
This was actually the main reason I looked at this; bzr builddeb
understands tags, and it's a lot easier for me to upload new Debian
packages by just running "bzr mu" than to first figure out which
upstream revision I should merge and build against.

> Basically, I like the idea, but I think the actual actions are
> incomplete. We need to settle on a tagging/naming scheme, and then the
> instructions need to be updated to figure out how to get these tags back
> into the system.
Thanks - I thought this was already policy but just not always
happening. Tags can be quite useful sometimes (and not just for
packaging), so it would be nice to have them set on bzr.dev.

Cheers,

Jelmer

-- 
Jelmer Vernooij <jelmer at samba.org> - http://samba.org/~jelmer/
Jabber: jelmer at jabber.fsfe.org