Release management - best practice

Question

I work for a product development company.We first do internal releases,and then public release.I was wondering, how other product developing companies manage their release? How do you give release number? Tag the source control?

Regan

Answer 1

We use SubVersion, where tags and branches are cheap to create.

As far as releases go, we follow this convention:

(Major Release).(Minor Release).(Patch Release).(SVN revision)

• Patch Release = bug fixes
• Minor Release = binary compatible / interface compatible
• Major Release = includes breaking changes.

Does that make sense? If you need more information, add a comment and I'll edit my post to clarify.

Pollster

I'm not sure I'd call Subversion branches and tags cheap to create... at least, not after having used Git anyways. – Synagogue

What Bob said — we're about to move from Subversion to Git, partly because branching and tagging are so much less expensive in Git than SVN. whygitisbetterthanx.com is a good comparison of several VCSes, though with an obvious preference for Git. – Atory

Answer 2

I created a similar question, but I wanted to add to this: I strongly recommend using something like Jira to manage a release cycle. You can associate commits with requests/issues/bugs, and then flag those as part of a release.

In particular, if you want to know how to manage a good release cycle, have a look at how the Apache foundation does it, because they have it down to a science. For instance, here's the roadmap for releases in the Mahout project.

Along with a working system that tracks issues and bundles them in a release package, you will want to start integrating this with your continuous integration (I've used both CruiseControl and Hudson) and unit tests so that your build cycle is managed along with everything else.

Catacaustic

Answer 3

I worked for a custom software provider that eventually morphed into a solutions provider when customers decided that they didn't want to implement their own callcenters and websites.

In that environment, each major customer had an opportunity to customize some aspects of how the system worked. So development had a core product with components common to all contracts, and separate branches for each customer (some customers needed minor tweaks, others major integration with other systems).

It worked ok, until the business grew and the number of branches expanded, often to accommodate really lame changes. At one point I think they had something like 15 different active versions of the same codebase... which made things really inflexible and difficult to support.

Don't do what we did -- make your releases scale!

Sleek

Answer 4

As others said, the best way of dealing with managing realeases is by branching. I highly recommend taking a look at the TFS Branching Guide (http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785) which explains several approaches to creating the branch structure depending on the size of your projects and different ways of providing your software to end-users (major releases, service packs, hotfixes). Most of the is not specific to TFS so you can apply it to most other source control systems.

Barmecide

Answer 5

At my company, when a release is ready, we create a branch for the major/minor release numbers, called something like R_2_1. The initial release is done by making a snapshot branch or label immediately afterwards, called R_2_1_0. When QA files bugs against a release, code changes are made on the R_X_Y branch, and then an R_2_1_1 branch is created to mark that release. So the tree looks like this:

Mainline
|
|- R_2_1
|  |
|  |-R_2_1_0 (locked)
|  |
|  |
|  |-R_2_1_1 (locked)
|  |
.  .
.  .
.  .

Marleah

Answer 6

We use SVN and create two branches for each release. One is a tag of the source code used to build this release, and one is a new import of the actual released binaries. This is important because (no matter how much you try to make two developers' machines the same, or try to maintain a stable build machine) inevitably when you come to try to regenerate build X 6 months down the line, you will find that something has changed and the binary that results is subtly different.

Minor patches are made in branches copied from the release source branch, and merged into the trunk. A minor release can then easily be made by copying the release source branch to a new branch and merging in whichever patches are required.

Major work is carried out in branches copied from the trunk, and merged back into the trunk when complete. Major releases can then be made from the trunk.

Bigname

Answer 7

An answer based on ITIL framework (that's more or less equal to the other ones).

ITIL classifies releases in 3 groups: major software release, minor software release and emergency software fixes.

From ITIL books:

•Major software Releases and hardware upgrades, normally containing large areas of new functionality, some of which may make intervening fixes to Problems redundant. A major upgrade or Release usually supersedes all preceding minor upgrades, Releases and emergency fixes.
•Minor software Releases and hardware upgrades, normally containing small enhancements and fixes, some of which may have already been issued as emergency fixes. A minor upgrade or Release usually supersedes all preceding emergency fixes.
•Emergency software and hardware fixes, normally containing the corrections to a small number of known Problems

So, following this you should have:

Major: v1, V2, v3, etc
Minor: v1.1, V2.1, etc
Emergency: v1.1.1, V2.1.1, etc..

Almanac

Your question is on topic on the ITIL Stackexchange – Helpmate

Answer 8

Follow-up to co-cat's answer regarding TFS. There is a new URL with some updates for VS2010 and VS11

http://vsarbranchingguide.codeplex.com/releases

Dutiful