Is there any guideline or standard best practice how to version a software you develop in your spare time for fun, but nevertheless will be used by some people? I think it's necessary to version such software so that you know about with version one is talking about (e.g. for bug fixing, support, and so on).
But where do I start the versioning? 0.0.0? or 0.0? And then how to I increment the numbers? major release.minor change? and shouldn't any commit to a version control system be another version? or is this only for versions which are used in a productive manner?
This question is related to
versioning
I would use x.y.z kind of versioning
x - major release
y - minor release
z - build number
We use a.b.c.d where
As Mahesh says: I would use x.y.z kind of versioning
x - major release y - minor release z - build number
you may want to add a datetime, maybe instead of z.
You increment the minor release when you have another release. The major release will probably stay 0 or 1, you change that when you really make major changes (often when your software is at a point where its not backwards compatible with previous releases, or you changed your entire framework)
The basic answer is "It depends".
What is your objective in versioning? Many people use version.revision.build and only advertise version.revision to the world as that's a release version rather than a dev version. If you use the check-in 'version' then you'll quickly find that your version numbers become large.
If you are planning your project then I'd increment revision for releases with minor changes and increment version for releases with major changes, bug fixes or functionality/features. If you are offering beta or nightly build type releases then extend the versioning to include the build and increment that with every release.
Still, at the end of the day, it's up to you and it has to make sense to you.
You know you can always check to see what others are doing. Open source software tend to allow access to their repositories. For example you could point your SVN browser to http://svn.doctrine-project.org and take a look at the versioning system used by a real project.
Version numbers, tags, it's all there.
We follow a.b.c approach like:
increament 'a' if there is some major changes happened in application. Like we upgrade .NET 1.1 application to .NET 3.5
increament 'b' if there is some minor changes like any new CR or Enhancement is implemented.
increament 'c' if there is some defects fixes in the code.
I use this rule for my applications:
x.y.z
Where:
Example:
There is also the date versioning scheme, eg: YYYY.MM , YY.MM , YYYYMMDD
It is quite informative because a first look gives an impression about the release date. But i prefer the x.y.z scheme, because i always want to know a product's exact point in its life cycle (Major.minor.release)
I start versioning at the lowest (non hotfix) segement. I do not limit this segment to 10. Unless you are tracking builds then you just need to decide when you want to apply an increment. If you have a QA phase then that might be where you apply an increment to the lowest segment and then the next segement up when it passes QA and is released. Leave the topmost segment for Major behavior/UI changes.
If you are like me you will make it a hybrid of the methods so as to match the pace of your software's progression.
I think the most accepted pattern a.b.c. or a.b.c.d especially if you have QA/Compliance in the mix. I have had so much flack around date being a regular part of versions that I gave it up for mainstream.
I do not track builds so I like to use the a.b.c pattern unless a hotfix is involved. When I have to apply a hotfix then I apply parameter d as a date with time. I adopted the time parameter as d because there is always the potential of several in a day when things really blow up in production. I only apply the d segment (YYYYMMDDHHNN) when I'm diverging for a production fix.
I personally wouldn't be opposed to a software scheme of va.b revc where c is YYYYMMDDHHMM or YYYYMMDD.
All that said. If you can just snag a tool to configure and run with it will keep you from the headache having to marshall the opinion facet of versioning and you can just say "use the tool"... because everyone in the development process is typically so compliant.
Yet another example for the A.B.C approach is the Eclipse Bundle Versioning. Eclipse bundles rather have a fourth segment:
In Eclipse, version numbers are composed of four (4) segments: 3 integers and a string respectively named
major.minor.service.qualifier. Each segment captures a different intent:
- the major segment indicates breakage in the API
- the minor segment indicates "externally visible" changes
- the service segment indicates bug fixes and the change of development stream
- the qualifier segment indicates a particular build
I basically follow this pattern:
start from 0.1.0
when it's ready I branch the code in the source repo, tag 0.1.0 and create the 0.1.0 branch, the head/trunk becomes 0.2.0-snapshot or something similar
I add new features only to the trunk, but backport fixes to the branch and in time I release from it 0.1.1, 0.1.2, ...
I declare version 1.0.0 when the product is considered feature complete and doesn't have major shortcomings
from then on - everyone can decide when to increment the major version...
Source: Stackoverflow.com