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

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)
|  |
.  .
.  .
.  .

Answer 2

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..