Hannes
Hannes

Reputation: 5282

Mercurial: Branching for releases?

Previous history: The last couple of years I used SVN. Releasing a new version of a software project included following steps:

  1. creating a branch for the new release: /repo/branches/0.1
  2. getting the code into a release-worthy state there
  3. creating a tag for a release candidate: /repo/tags/0.1-RC1
  4. creating branch for RC1 to fix bugs: /repo/branches/0.1-RC1
  5. creating tag for a new release candidate: /repo/tags/0.1-RC2
  6. {...}
  7. creating a tag for v0.1 from the last RC: /repo/tags/0.1
  8. merging 0.1 into trunk

As far as I got Mercurial sees branches and tags slightly different than SVN and this finally leads to my question:

Do I create branches (and tags) for releases? And if not: What else wants Mercurial me doing to archive something similar to the described development pattern/cycle?

Upvotes: 0

Views: 74

Answers (2)

Lazy Badger
Lazy Badger

Reputation: 97355

You can use old workflow, but:

  • Branch per release really needed (in any SCM) only if you have to maintain some amount (>1) of releases in production at the same time, gor single maintained release branches-tree not needed
  • I see a lot of (rather complex) projects, which use two-branches method ("Stable" with mergesets only and tags + "Devel" for every-day development (short-term branch-per-task are also possible, but it's more question of tastes and habits, than "a must")

Upvotes: 1

Ringding
Ringding

Reputation: 2856

You can easily keep using this method. I'm not sure what you'd need a separate RC1 branch for, but I guess there are good reasons.

There is a bit of an annoyance in the way tags are stored in Mercurial, which is a versioned file listing them one by one. As a result tag creation constitutes a changeset. You should strive to keep all such tag-creating changesets on one branch, or you will get merge conflicts (which are easily resolved, but annoying nonetheless).

Upvotes: 1

Related Questions