[rfc] merging release branches back into bzr.dev

John Arbash Meinel john at arbash-meinel.com
Wed Oct 3 13:10:17 BST 2007


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

Aaron Bentley wrote:
> Martin Pool wrote:
>> Our current instructions for making releases say that after doing the
>> release, the rm should make an untracked merge back into trunk.
> 
>> I can see two main reasons for this: one is that it prevents people
>> accidentally pulling trunk into a branch that's based on the release;
> 
> Another way we can avoid this is by upgrading the branch to
> dirstate-tags, and setting append_revisions_only to True.
> 
>> the other is that it's arguably incorrect to merge the change that
>> gave the release it's version number.
> 
> I guess I see what you mean, but I think the benefits are worth it.  If
> we feel the need to lie to Bazaar about what's been merged, we should
> figure out why, and fix it.
> 
> Aaron

Not to mention that we have

a) Official locations for these branches
b) 'tags' support so that we can give an official this is release 0.91.0
c) append_revisions_only so that you can only pull if the mainline lines up.

I'm very much in favor of doing a full merge. One thing I miss about our setup
is that I cannot produce a release codebase from bzr.dev. (Because we skip
revisions that are not in your ancestry.)

I think you can do 0.10.0 or whichever one I did (before I started following
policy.) :)

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

iD8DBQFHA4apJdeBCYSNAAMRAhmvAJ9EEpxAD8Jvcl2yJa+5T81FPzTBMACg0Pt8
aMaBlu8QbF8fR27carri+uU=
=FPgI
-----END PGP SIGNATURE-----



More information about the bazaar mailing list