Page 1 of 1
Assign Version Numbers - Best Practices?
Posted: Fri Jul 18, 2008 4:31 pm
by bluesman333
Is anyone aware of a list of best practices for assigning version numbers to application releases? I'm using Subversion for version control; up until now, I haven't been tagging my releases. Should I just start at 1.0?
Re: Assign Version Numbers - Best Practices?
Posted: Fri Jul 18, 2008 7:42 pm
by dreamscape
I've taken to basing my versioning on Apple's versioning based on the NumVersion Struct.
Here are how I lay out the basic rules (taken from Apple and slightly adjusted):
Code: Select all
Versioning that is based on the NumVersion Struct
Has the following revision indicators:
[major revision].[minor revision].[bug revision]-[stage][stage revision]
Major revision increments indicate significant changes and/or jumps in functionality and/or programming
The major revision number begins at 1 and increments from there.
The major revision number may not jump or skip any revisions.
Minor revision increments indicate minor feature changes and/or significant bug fixes.
The minor revision number is limited to a single digit, 0 - 9.
The minor revision number may jump or skip revisions if there are significant changes,
but not significant enough to warrant a major revision increment. As a general guide,
the jumping should be done in increments of 5 revisions, thus allowing only one jump per
major revision before the major revision must be incremented. Minor revision releases may
be referred to as "point releases".
Bug revision increments indicate minor bug fixes.
The bug revision number is limited to a single digit, 0 - 9.
The bug revision number may not jump or skip any revisions. If there are significant enough
fixes to warrant such a revision jump, the minor revision should be incremented instead.
Stage indicator:
Consists of a string belonging to one of "dev", "alpha", "beta", "rc", or "final", where:
"dev" stages are internal private releases
"alpha" stages are very early releases that may or may not be plublic releases
"beta" stages are public releases intended for early adopters and other "beta testers"
"rc" stages are release candidates indended for more widespread testing
"final" stages are stable releases and should be "production worthy"
Stage revision:
The stage revision number begins at 1 and increments from there.
The stage revision number may not jump or skip any revisions.
In the case of final stage releases, the stage and stage revision indicators are omitted.
Only the final release stage may increment the other revisions.
When a revision indicator's number increments, all lower revision indicators should roll back
to their starting position.
Feel free to use or modify.
Re: Assign Version Numbers - Best Practices?
Posted: Sat Jul 19, 2008 6:44 pm
by alex.barylski
Personally I use something similar to Linux kernel in that version numbers will tell me how many times something has occured:
Convention: a.b.c.d
a = Major version number. Incremented when I have changed something in the architecture large enough that it warrants a new release
b = Revision number. Borrowed from SVN.
c = Bug counter. Incremented when I have fixed a bug.
d = Security counter. Incremented when I have fixed a security hole.
I like keeping tabs on how many bugs or security holes I've fixed so I keep that information in the version number otherwise it's something I'd loose.
I don't like the idea of Beta or release candidates, or incomplete versions such as 0.1.1
Re: Assign Version Numbers - Best Practices?
Posted: Wed Jul 23, 2008 1:14 pm
by JAB Creations
I pretty much agree with Hockey on this one...
I start with 1.0 on anything I work with. My site is a little different however. For example it's currently "Version 2.8 Preview V". Version 2.8 = 28th version of my site (extra version makes the 8 = 8th instead of how century such as 1700s = 18th century). For me I don't declare a version final until I've completed everything during the design and development phase that I can achieve.
Besides my website I consider any patch (security related or not) as an incremental update depending on the project.
For projects where I may add some moderately large features I'd do something such as 5.1.0 and minor updates as 5.1.2.