Equivalent to svn tags?
Jamu Kakar
jkakar at kakar.ca
Wed Oct 24 01:08:05 BST 2007
Hi Matthew,
Matthew Tylee Atkinson wrote:
> My (current ;-)) question is this: what is the equivalent of svn tags in
> bzr? I gather that one would make a new branch when a release series is
> started (say 0.3.0, branched from trunk) and then develop on that to
> make, for example, 0.3.1, 0.3.2 and so on.
>
> However, using this approach would mean that commits to 0.3.0 before it
> becomes 0.3.1 would cause the 0.3.0 branch to eventually contain some
> code that was not included in the actual 0.3.0 release. I'd really like
> to make tags that preserve a record of releases for prosperity; not just
> allow us to make new lines of development. I suppose the answer to that
> is that I should really make a tarball of the 0.3.0 branch at the moment
> it is started, to keep /that/ as the copy for posterity and then
> continue developing the branch and branch 0.3.1 (taking a copy tarball
> of that, too) as and when required.
It's actually easier than this because of Bazaar's smart merging
behaviour. Here's what we do on a project I work on:
We have a trunk branch which represents the most current stable
version of the code. When it's time to implement a feature, let's say
"Bug #123: We need a login page", I create a branch for that feature:
bzr branch trunk login-ui
I work in the login-ui branch until I'm satisfied that my changes
satisfy the needs of the feature. At this point I notify my
colleagues that I have this branch which fixes bug #123. They review
it, I make the requested changes, and when everyone is happy I merge
it to trunk. This is how trunk is "stable"; only complete chunks of
work land in trunk. All the intermediate work before the feature is
ready happens in the branch.
Now, let's say we've got a few features landed in trunk and it's time
to do a release, say 0.3.0 to use your example. I could create an
0.3.0 branch, but doing so would result in quite a few branches after
I've made a number of releases, which I would prefer to avoid having
to maintain. Instead of having a release-specific branch we have a
branch called "production". So, making a release is basically:
cd production
bzr merge ../trunk
./test
bzr commit -m "Merged trunk."
bzr tag 0.3.0
Now the production branch has a tag that represents the revision for
0.3.0. Someone then comes along and reports bug #124. Despite being
careful with tests and review, a bug has slipped through in my
login-ui branch. The fix is easy and I want to get it out ASAP. At
this point I:
bzr branch production login-ui-fix
I then implement the fix in login-ui-fix, get it reviewed, and when
everyone is happy I merge login-ui-fix into the production branch:
cd production
bzr merge ../login-ui-fix
./test
bzr commit -m "Merged login-ui-fix (#124)."
bzr tag 0.3.1
Great, now the fix has been landed in the production branch and
whatever deployment process is required can be performed to get it out
to my users. I want to make sure my production and trunk branches
don't diverge. At this point I:
cd trunk
bzr merge ../production
./test
bzr commit -m "Merged production."
Now the fix is in trunk and everyone is happy. In practice we also
have a staging branch that we merge trunk to sometime before merging
staging to production, but the basic process is the same. I guess
this doesn't really answer your question about how to work with
release series in Launchpad. I don't really know the answer to that,
but hopefully someone else will.
Hope this helps,
J.
More information about the bazaar
mailing list