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
Requires package decision logic
Although this is a non-standard versioning logic, do you guys see any problems with this logic?
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. :)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With