have a release branch

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Colin D Bennett wrote:
> On Fri, 13 Feb 2009 13:11:43 +1100
> Robert Collins <robertc at robertcollins.net> wrote:
> 
>> I'd like to change/add to how we do releases the idea of having a
>> 'current' branch of bzr.dev, which is always the current release.
> 
> Sounds good.
> 
>> Basically just 'bzr push 1.12 current' now, and then after each full
>> release (not beta etc) either push to current again (tags letting us get
>> at older releases there), or merge to current (left hand history in
>> current is each release).
>>
>> I think merge to current is probably most useful.
> 
> I guess it depends on how current will be used.  In my mind, ‘current’
> would be conceptually a symbolic link to the latest released version,
> or, equivalently, could be thought of as a persistent, movable tag
> referring to the latest release version:  persistent meaning checkouts
> can be kept up to date, and movable meaning that the revision referred
> to changes with each release.
> 
> I think a point in favor of pushing is that with merging (correct me if
> I'm wrong) the revision-id of bzr 1.13 in the ‘current’ branch will not
> be equal to the revision-id of bzr 1.13 in the ‘bzr.1.13’ branch, which
> would seem weird to me.  I wonder if push (--overwrite?) would be
> best, so that the ’current’ branch can be treated as an exact mirror of
> the latest release branch?
> 
> What is the advantage of merging over pulling?
> 
> Regards,
> Colin

I'm pretty sure Robert's idea is to no longer *have* a "bzr 1.13" branch.

So you would end up with 2 branches.

1) bzr.dev - the active development trunk
2) bzr-released - When we get ready to do the next release, we submit a
merge request for 'bzr.dev' to be merged into 'bzr-released'. After that
is merged and commited, we "bzr tag" it to be bzr-X.YY

Then 'bzr log --short' would, in theory, look like:

  3000 PQM [merge]
       Release 1.11

  3001 PQM [merge]
       Release 1.12rc1

  3002 PQM [merge]
       Release 1.12

  3003 PQM [merge]
       Release 1.13rc1
...

In theory, that looks nice and clean. I think in practice we still need
a way to do focused patches towards the release branch. We had 3-4 post
1.12rc1 patches to 1.12, but we had 8+ patches to bzr.dev post 1.12
release. We didn't want all of those bzr.dev changes in 1.12, but we
needed *some* of them. In which case the log looks like:

  3000 PQM [merge]
       Release 1.11

  3001 PQM [merge]
       Release 1.12rc1

  3002 PQM [merge]
       Fix foobar for clarity.

  3003 PQM [merge]
       Fix bug #123456, was breaking https

  3001 PQM [merge]
       Release 1.12

...

Which I think is still ok. Not quite as clean as a pure-release branch.
Where every release is just one commit on the mainline. However, it
works pretty much exactly the same as we do now. Once 1.13 is out, we
don't expect any more commits to 1.12. I think we've gotten pretty close
to having a 1.X release overlap with a 1.X+1rc1 release, but it isn't
common.

In then end:

1) I like having a single branch, if only so that we don't have to ping
lifeless to make a new branch for us every month. He does great, but
he's probably going to be on vacation one of these times.

2) We need to get tags working with PQM before I'd really be
comfortable. Right now, tags seem to go into a black hole when they go
through PQM.

3) It would be *nice* to have a way to ask PQM to tag a branch. Either
tag the commit it makes, or after the fact. (So you could 'bzr
pqm-submit --create-tag bzr-1.12 -m "Release 1.12"', and PQM would add a
"bzr tag bzr-1.12" after the commit succeeded.)

We can always do it locally and the tag propagates when we merge it back
into bzr.dev. And then you would get old tags in bzr-release. The main
problem is that you can't get the *current* tag in there.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmVf1QACgkQJdeBCYSNAANPoQCgweowpDgHNpjg5KzVOuzefW+3
ktwAn2S9WjW+kTR8PRGpsXuUUv1wnp3u
=gB3O
-----END PGP SIGNATURE-----