Code version change "rules"

Question

I know that there are no fixed rules about software version control but I have several questions.

1) How to upgrade versions correctly

I have a small software that I started a while ago and since i started from scratch I started with version 0.1.

As I added more functionality I have been upgrading the minor number. Now I'm in v0.5.7 (minor (.5) for new functions and revision (.7) for bug fixes and minor changes), the thing is that the program is almost complete for distribution, but now I'm "missing" several minor versions, how do you guys handle that situation? do you simply just jump the numbers?

That brings me to the second question.

2) Which is a good starting version number

I am about to start a new project. This time is not that small of a project and is going to be public and free for modifying, I do not want to have the issues mentioned above. So which would be a good starting point?

Bonus question:

3) Is it ok to make numbers above 10? like v1.25 or v2.2.30?

I haven't seen software with that kind of numbering (probably they show it only in the help section or in their web-page), again I am aware that there are no rules for that but it seems to be that there is a general consent on how to keep the version numbers.

Solution 1

Version numbering policies can be a bit crazy at times (see Version numbers and JSR277, or Oracle, with its Oracle Database 11g Release 2: 11.2.0.1.0.
See also Software Versioning is Ridiculous).

But you can start by looking et the Eclipse Version Number policy as a good start.
If you really think you need more than three digits, this V.R.M.F. Maintenance Stream Delivery Vehicle terminology explanation is also interesting, but more so for post 1.0 softwares, where fix pack and interim fixes are in order.

---

1/ "Ship it already": 1.0.0

Also known as the "1.oh-oh" version. At least, it is out there and you can begin to get feedback and iterate fast.

2/ 0.x if major features are still missing; 1.0.0 if the major features are there.

3/ Yes, but I would say only for large projects with a lifespan over several years (a decade usually)

---

Note that "correctly" (while being described at lenght in Semantic Versioning 2.0.0) can also be guided by more pragmatic factors:

See the announcement for Git 1.9 (Januaury 2014):

A release candidate Git v1.9-rc2 is now available for testing at the usual places.

I've heard rumours that various third-party tools do not like the two-digit version numbers (e.g. "Git 2.0") and started barfing left and right when the users install v1.9-rc1.
While it is tempting to laugh at them for their sloppy assumption, I am also practical and do not mind calling the upcoming release v1.9.0 to help them.

If we go that route (and I am inclined to go that route at this moment), the versioning scheme will be:

• The next release candidate will be v1.9.0-rc3, not v1.9-rc3;

• The first maintenance release for v1.9.0 will be v1.9.1 (and Nth one be v1.9.N); and
• The feature release after v1.9.0 will be either v1.10.0 or v2.0.0, depending on how big the feature jump we are looking at.

---

Update Feb. 2019: semver itself is about to evolve (again, after semver2).
See "What’s next for SemVer", and semver/semver/CONTRIBUTING.

Solution 2

At our company, we are using four token versioning concept. It's something like a.b.c.d kind:

(major).(feature).(revision).(bug/refactoring)

It's related with issue types which we use in our development life cycle. We can track what has done or changed between two following versions at a glance. By comparing two following version numbers you can identify number and types of issues done. For more information, full documentation is here.

Solution 3

Even i faced this problem with defining the version number while developing with CRM, since i wanted to deploy the same build across all the systems. I found a way to resolve it with System value + Manual + randoms.

The version information for an assembly consists of four values:

Major Version . Minor Version . Build Number . Revision

Which makes the initial Version 1.0.0.0 by default. To make more sense i replace it with

TFS Release . TFS Sprint . Change Number . Incremented build number

Suppose in your TFS a single release consists 30 sprints and after that the release becomes 2, so the values for the first release will be:

TFS Release : 1

If the current sprint is 4, the TFS Sprint will have

TFS Sprint : 4

Now the third part is managed by the developer, for a initial version we can have 0 which can be incremented +1 for each ChangeRequest or BugFix.

Change Number: 0 -- represent initial version Change Number: 1 -- represent change Change Number: 2 -- represent bugfix

Although for every bugfix there might be a change in code, so it represents the code change as default. But to more more sense you can have the odd number to represent the change and even number to represent the bugfix.

The last part was the default number, thankfully .Net allows us to put * to put a default build number. It keeps on increment with every compile/build which provides a signature stamp, if someone else rebuilds it changes.

How to Implement:

Open the AssemblyInfo.cs in the Properties folder and Comment the AssemblyFileVersion, this will make the AssemblyFileVersion & AssemblyVersion same.

// You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
[assembly: AssemblyVersion("1.4.2.*")]
//[assembly: AssemblyFileVersion("1.0.0.0")]

So the final version will come out as: 1.4.2.4512 or something

The benefits of this approach is that you can track the Task for which the code is generated. Just by looking at the version number i can say, "Hey its the release 1 for sprint 4 and with some code change.

Solution 4

Semantic Versioning is pretty much de facto nowadays.

I'm "missing" several minor versions, how do you guys handle that situation?

You're not missing versions. It's perfectly acceptable to… (see next answer)

Which is a good starting version number

Depends if people are using your code in production. If it's already used in production jump straight to v1.0.0. But since you said your code is alpha, beta, or rc (release candidate) quality but you're planning to move to production quickly consider starting with v1.0.0-[alpha].N where [alpha] is the software grade and N is a build number or other enumerable value.

Is it ok to make numbers above 10? like v1.25 or v2.2.30?

That's the idea. Lexicographical sorting may not work but that's okay.

View more solutions