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?

Answer 1

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!

Answer 2

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.

Answer 3

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

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.

Answer 5

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.

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.