[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