8

We are in a process of changing the versioning and dependency system of ours Middleware (MW) software, and we where thinking on something like this:

a.b.c.d

a - Major version

b - Backwards compatibility break

c - New functionality

d - Bug fix

But with a little twist, since we must keep to a minimum the number of packages we send to the clients due to the size of the software and the slow network.

So the idea was to only reset the Bug Fix number on a Backwards Compatibility change. Using this logic we could create an automatic system that only generates a new package if there were any bug changes over the version that the client already has installed, and that it complies with what the new FrontEnd (FE) requires.

To better display this all scenario here are a couple of examples:

Increment logic

Increment logic

Requires package decision logic

Requires package

Although this is a non-standard versioning logic, do you guys see any problems with this logic?

Gonçalo Cardoso
  • 2,253
  • 4
  • 34
  • 63

2 Answers2

1

There is no problem skipping version numbers (or having complex version numbering) as long as you have internal logic that your whole company understands and abides by. (If things don't change... Microsoft is going to be skipping version 9 of it's windows systems.)

[major].[minor].[release].[build] is used quite a bit by many companies.

At our company, we added one extra beyond [build] called [private].
[major].[minor].[release].[build].[private]

In our logic, [private] is used for internal sequencing for bug testing. (We purposely break our code so we can test for bugs.) But before releasing the code, [private] must be set back to zero. Thus, no code leaves the office unless there is a .0 sitting at the end of the Version number. It's a reminder for programmers to remove (or comment out) their test coding and it's a reminder to testers not to send out code that's only meant for testing.

Back in the 80's I also read something about the psychology of version numbering. Some companies would jump directly to [minor] release 3 just to make it look like they had done more testing than they really did. They also avoided going above 7 because it made them look like they were fixing too many errors and were prone to having horribly buggy code. This psychological perception of the customers or clients can be fairly strong and can be a huge debate between programmers (who tend to rightly be literalists) and marketing people (who treat logic like some fluffy after thought).

With this in mind, to answer your question: Your logic is fantastic... now go sell it to your marketing department. (Or better yet... don't sell it to them, just implement it and hope they don't come knocking on your door, or cubicle, or hiding place.)

Best of luck with your design. :)

abraxascarab
  • 661
  • 1
  • 6
  • 13
0

[major].[minor].[release].[build] (widely accepted pattern from this post: https://stackoverflow.com/a/615277/758378)

Deviating from the pattern

You have a specific reason for doing this, so I don't see any problems. (Your specific logic seems fine to me as well.)

About not resetting the last number

This is really not a problem at all. In answer linked above, you can even see using SVN revision as a suggested number to use.

Community
  • 1
  • 1
Tmarty
  • 477
  • 5
  • 10