CODEWITHSUNDEEP
mercurialworkflowdvcsrelease-management
Roger
Roger

Reputation: 1950

Hg workflow with two different release cycles

We're about to change our workflow for our release management as part of our upgrade from a CVCS (TFS) to DVCS (Hg). Some things have been discussed pretty intense here at office and I would be glad to get some input about it.

Some background

We're a small/midsized software company (approx. 25 developers) with a long lived product. We try to keep our release cycles low - a release after each sprint (~once a month). In TFS we create a branch for each new release. The two last releases supports bug fixes.

Our current branch model (TFS)

--trunk
  --release200 //and older, not supported anymore
  --release201
  --release202

On top of these branches we have different developer branches (if needed). Some team branches and some feature branches.

"Small" bugs are corrected on release202 and merged to trunk. Critical bugs are corrected on release201 and merged to release 202 and trunk.

What we don't support is bug fixes on older releases.

New workflow

Some customers don't care that much about new features, instead they want a more stable version. Therefore we are thinking about offering two tracks - one long lived release with patches, another with more frequent updates of features. We've been thinking about having branches like this...

(Hg)

--default
  --RC
  --Release
  --StableRelease200
  --StableRelease210

These are all named branches inside a central Hg repository. Each of these branches is connected to a CI machine. From a developer perspective, there will be develop branches (hg clones) outside the scope of this question.

Some customers will use releases from Release, some from StableReleaseX.

Default: All new development of features is merged into this branch.

RC: When a PBI is done/end of a sprint, default is merged into this branch for internal testing. Bugs found in this branch is also corrected here. When QA thinks it's stable enough, this branch is merged into Release. If some developers need continue to work on new features, they can do it on Default.

Release: Releases here happens sequentially, only the last one will support bug fixes. From a technical perspective, releases are marked with Hg Tags. Critical bugs found at customer site during a sprint will be fixed here and merged back to default.

StableReleases: Every half year or so (decided by management), Release is merged to a new StableRelease branch. During its life time, no new features will be added here. Bugs found here will be fixed here and merged back all the way to default. Probably two StableReleases will be supported at the same time - the current one and the second last. Older branches will be closed.

Some questions

Upvotes: 1

Views: 481

Answers (1)

Martin Geisler
Martin Geisler

Reputation: 73778

Please see the wiki page on "standard" branching in the Mercurial wiki. You'll be glad to learn that it describes a workflow very similar to the one you propose! :-) So yes, having two release tracks like this works very well.

As for using named branches instead of clones, then we're very happy with the two names branches we use in the Mercurial project itself. We used to have two repositories, but now have a default and a stable branch.

The reason why some prefer separate clones on the server is that it might give a better overview: the "branches" then show up as separate repositories.

Upvotes: 1

Related Questions