Page 1 of 1
Versioning
Posted: Fri Jan 27, 2006 12:19 am
by alex.barylski
I've always used the linux kernel numbering system:
1.0.0 for example...where...
I will assume you know how the version numbers work...
What I want to know (if you use this numbering system) is what do you use as a metric to justify starting a new major version or increment of the other two values...
Knowing that odd is development and even is stable???
My approach maybe isn't practical for large projects likes Linux kernel, but it's justified for small projects (under 10,000 lines)...
Everytime I rewrite a major portion of codebase - refactoring hacks or updates, etc...
I consider that a major version increment...
I update the release number incrementally for every change I make in my code after a 1.0.0 release...
So, for example, if I change a spelling mistake, I increment the number to 1.0.1 and one number again for every change I make...
When that number reaches 99, I would then increment the preceeding digit by one and the release number is reset to zero...
I know this is non-conforming to Linux kernel standards, but my project isn't exactly linux and doesn't have a huge user base or community behind it, so differentiating between stable and development release aren't really nessecary...
Perhaps, I should drop the 1.0.0 and use 1.0 instead, but I just like this system better, so I'll likely continue to use it...
So I ask, considering how I deviate from the kernel numbering system slightly and assuming you use something similar, what do you use to justify a release number increment???
Do you increment the number for "every" change or do you use another system?
Re: Versioning
Posted: Fri Jan 27, 2006 1:38 am
by feyd
Hockey wrote:What I want to know (if you use this numbering system) is what do you use as a metric to justify starting a new major version or increment of the other two values...
I use a slightly different numbering system, an extension of the linux one with an added build/bugfix number: x.x.x.x
Each major version has a set of goals to achieve. It may be large or small, it doesn't really matter too much. What does matter is your general set of goals is met, or adequately met in your mind. In the end, you can chose whatever you wish, however bouncing up the version numbers quickly can indicate to an end user that you have really buggy code. Too slow and development moves incredibly slow.
So here's what I do it: I create a list of the big goals I want to hit. Those are used as qualifiers for hitting the major version. Completing one of these goals increases the minor version. Each of these goals are further broken down into smaller sets of goals. Completing (near bug free, if not) one of the smaller goals increases the patch version. The build/bugfix number is only used internally. I try to not release a incomplete goal.
Now, traditionally, the patch number would be incremented for batches of bug fixes to a minor version being released. In terms of marketing, I would only market the major.minor component leaving the major.minor.patch shown in "detailed" information. To ease the understanding of what is newer on dev builds, it may be beneficial to use the timestamp YYYYmmdd instead of an incremental number.
Hockey wrote:Knowing that odd is development and even is stable???
That's a very strange way of setting it up, and could be VERY easily confused by people who do not understand your numbering scheme. However, since your projects are quite small, you really can choose whatever you like, but I would suggest something fairly intuitive for anyone.
Posted: Fri Jan 27, 2006 4:51 am
by Jenk
I too am used to using the unix version number method, but I've often asked "What constitutes a major change, from a small change?" or to be more specific where does the line stand between the two?
A bugfix is easy.. it's a bug fix. The functionality remains the same, but the bug is (hopefully) removed.
A functional change.. how big/small a functional change should it be to make it a new version or just a patch?
Posted: Fri Jan 27, 2006 5:39 am
by Maugrim_The_Reaper
I think the decision is largely up to you. Patch incrementing is simple enough, minor version incrementing I generally take as being actual feature additions/or functional improvements (not bug fixes, small functions, or other minor changes), major version increments I reserve for pretty big shifts - usually for meeting a preset list of goals that effect the entire application as a whole.
Its pretty ad-hoc really. I doubt any two developers could define a line separating each decision. Use whatever seems most intuitive without going overboard - I've seen some PHP apps increment a major numeral on the back of something small... Not too common thankfully...

Posted: Fri Jan 27, 2006 7:24 am
by Roja
I've recently changed my criteria for development, so I'll chime in with my ideas, however worthless they are.
As a general statement, I try to do roughly 10 bug fixes, and 10 improvements or changes each release. Once I get that many, I bundle it up, and make it a "Release Candidate". The RC is put through the paces, and any bugs we find, we try to address. Rinse and repeat a few times to make sure we don't miss any obvious bugs, and after 3-4 release candidates (or less if we are lucky!), we do the release. Each release, we generally increment the version number by a hundreth. So generally, from 0.50->0.51.
However, we do occasionally make leaps forward. By way of example, in BNT-0.50, the AI players were non-functional, and very buggy. By merging in code from a mod for BNT, we've leaped ahead by several releases (as measured by the 10/10 rule). So, we're now working on 0.55, not 0.51.
In addition, there are also large jumps for substantial events. We're working on the next generation version of BNT ("ProtonPack"), which will probably come out sometime around the time the Classic branch hits the high 0.60's. When it does, its going to be an incredibly different codebase, and as a result, we will increase our version number substantially to reflect that. (It won't be 1.0. 1.0 will be the result of substantial testing releases beforehand).
The goal, in my mind, is to make clear to admins when there is substantial value in upgrading, and to keep version numbers realistic. Sure, we could be on version 9.935893905, but what does that *mean* ?
Three digits are enough for us.

Posted: Fri Jan 27, 2006 7:29 am
by Jenk
One of the worst (well, not worst, just annoying) is the system this company uses..
if it's 0.x, it's in development, if it's 1.x it's been released.
There for 1.9 is actually 'version 9' and not 'version 1' which catches out a lot of people. There is no progression past 1.x btw.
Posted: Fri Jan 27, 2006 10:22 am
by AngusL
Only product where I use version numbers really is my operating system (kernel really at this stage, but it sounds good nonetheless

)
Version.Release.Revision.Build
Build increments every time I, er, build.

Spelling mistakes, typos, missing a semicolon all increment this - also incremented by fixing common bugs in code. This number therefore has little value other than to say that it might be a little less buggy.
Revision increments for small (rather than tiny) changes to code, normally within sections that are already defined (no real new functionality per se, just making what's there already act a little better, or deal with a few more circumstances). So if there's a bug that only occured under fairly exceptional circumstances, and I added a handler for these circumstances, it'll increment.
Release increments every time I add new functionality - supporting EXT2 drives in addition to FAT32 for example, would increment this. Adding networking support will increment this several times.
Version increments every time I add a set of pieces of functionality, to bring it up to a new level of 'completeness'. So adding a GUI say, might increment this. Otherwise, after adding a few large features, this might increment. Say... basic - multitasking, file system support, a GUI and networking support might increment this. It would then increment if these were signficantly built upon.
Re: Versioning
Posted: Fri Jan 27, 2006 6:55 pm
by alex.barylski
feyd wrote:Hockey wrote:What I want to know (if you use this numbering system) is what do you use as a metric to justify starting a new major version or increment of the other two values...
I use a slightly different numbering system, an extension of the linux one with an added build/bugfix number: x.x.x.x
Each major version has a set of goals to achieve. It may be large or small, it doesn't really matter too much. What does matter is your general set of goals is met, or adequately met in your mind. In the end, you can chose whatever you wish, however bouncing up the version numbers quickly can indicate to an end user that you have really buggy code. Too slow and development moves incredibly slow.
So here's what I do it: I create a list of the big goals I want to hit. Those are used as qualifiers for hitting the major version. Completing one of these goals increases the minor version. Each of these goals are further broken down into smaller sets of goals. Completing (near bug free, if not) one of the smaller goals increases the patch version. The build/bugfix number is only used internally. I try to not release a incomplete goal.
Now, traditionally, the patch number would be incremented for batches of bug fixes to a minor version being released. In terms of marketing, I would only market the major.minor component leaving the major.minor.patch shown in "detailed" information. To ease the understanding of what is newer on dev builds, it may be beneficial to use the timestamp YYYYmmdd instead of an incremental number.
Hockey wrote:Knowing that odd is development and even is stable???
That's a very strange way of setting it up, and could be VERY easily confused by people who do not understand your numbering scheme. However, since your projects are quite small, you really can choose whatever you like, but I would suggest something fairly intuitive for anyone.
Hmmmmm....
Interesting...I actually like your approach...
I really like the idea of Major.Minor.BugFix while keeping bugfix out of the marketing jargon...
Sweet
Thanks for the details
Posted: Fri Jan 27, 2006 8:06 pm
by m3mn0n
I tend to stick with the *nix way.
For what constitutes a major and minor version, I just use my discretion as best as I can. Normally it's easy to tell, since I go by effort/development time, & significance of the change to the overall system or section/module in that system.
Posted: Fri Jan 27, 2006 8:39 pm
by Roja
Sami wrote:For what constitutes a major and minor version, I just use my discretion as best as I can. Normally it's easy to tell, since I go by effort/development time, & significance of the change to the overall system or section/module in that system.
While I liked your 3.whatever.looks-solid release, I had plenty of problems with the 4.imbored.get-the-release-out-already release.
Dunno why.
Posted: Sat Jan 28, 2006 1:29 pm
by Buddha443556
I use a ...
Major.Minor.Fix Build
... numbering system for my source code (which includes PHP). [I use the word "fix" because I'm not making patches.] I build my PHP files from a common code base and the build number is incremented every time I rebuild a project. When my PHP framework is forked for a client's project it starts out at version 1.0.0. My build system uses a include path which is inherited by client's project. This way if I update one of the framework's source code files it updates all the other project that use that those files. A major change is one that involves the common code base or an addition to the framework and everything else is a minor or a fix change.
Label such a STABLE or EXPERIMENTAL or BACKUP usually find themselves on project archives (zips) and have nothing to do with the version numbers being even or odd.
Posted: Mon Mar 13, 2006 4:46 pm
by Chris Corbyn
I'm a bit random.
I start at 0.1.0
Bug fixes increment the last number by one each time so a few bug fixes in one go makes the version 0.1.1.
If I make a minor change (this includes refactoring in my book) (not a fix),I'll change the second number and reset the third. So it becomes say 0.2.0 again.
Major changes are complete versions so I'd jump to version 1.0.0 when I make the first big overhaul. I've never gone past version one neither. I always get hooked up on a newer, more exciting project
EDIT | And why on earth did I just reply to this old thread?

I blame feyd for linking to it
