I didn’t learn programming at school and I do not work as a (professional) developer, hence a lot of basics are not quite clear to me. This question tries to clarify one of them.
Now let’s suppose that I have issues #1, #2 and #3 in my Issues Tracker that are set to be corrected/enhanced for version 1.0.0 and that the last (stable) version is 0.9.0.
When should I increment to version 1.0.0 ? When a) just one of the listed above issues is closed or b) when all the issues related to version 1.0 are closed ?
Which one is the right way to do it ? And by the right way, I mean what is currently used in the industry.
4
I can tell you how I do it at work.
We have a continuous integration server that builds, tests, tags and outputs a versioned package. We only proceed to the next stage if the previous one is %100 successful.
Our version looks like this: <Major Version>.<Minor Version>.<Build Number>
- Every successful build that has no completed bug fix or feature enhancement increments the Build Number.
- Every successful build with a completed bug fix or feature enhancement increments the Minor Version. This is automatically detected by the presence of a commit message using a particular format. This commit message also automatically get’s pulled into the projects ChangeLog.
- Every Major Version increment is done by hand when we have non backward compatible changes, rewrites from scratch or other reasons made on a case by case basis.
4
Version numbers are only relevant for releases, since they are a way for external users to identify a specific build of your software. If you’re just busy doing development and not releasing each fix individually, then don’t worry about incrementing the release number for every fix. It’s not relevant to external users and wastes your own time with extra version bookkeeping.
10
For continuiously deployed web applications, we tend to construct build numbers using symver up front and a build number tailing, ie: 2.5.3.4328 where 4328 comes from the continuious integration system. General expectation is that numbers change by deliberate steps but that the build number is the true unique ID.
What it seems to be doing here is capturing the day of deployment and the related svn build number:
<div id="svnrev">
rev 2013.10.21.1078
</div>
For what it’s worth.
The other answers are great already, so I’ll only add on top of them. If your software is not released and you don’t really need public versioning (the non-public versioning is your VCS), then append the keyword “SNAPSHOT” at the end of your version. Some systems, especially in dependency management, treat snapshots differently from released versions in that they compare the change date of the snapshots instead of the version number. So if you had a v. 1.0.0-SNAPSHOT from 8am in a package repo and a local dependency downloader has the same version from 7am, it shold download the updated one from the repo.
As said above, your private versioning is provided by your version control system (git, svn etc.).
There’s enough said about the theory of versioning here’s another viewpoint.
When should I increment to version 1.0.0 ?
I’m going to focus my answer on change of the major version number.
My answer is: Basically when you’re ready for it. Going from 0.9 to 1.0 is a big thing, because public perception will be that you’re going from a beta-product to an official release.
(I’m going to assume here it’s a commercial product from a company).
A few questions before going from 0.9 to 1.0.
Does your organization have the time to inform all your current clients.
To throw a party.
Get a lot of support requests.
An account manager to sell your product?
Etc. etc.
Yes I see the versioning as a marketing tool and if you look around you see that that basically is the industry standard.
Our company went from version 2.x to 3.0 and had a great party, created a lot of buzz and because of that got quite a few new clients. Apart from some interface updates the differences between the versions were quite minor.