Versioning

Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy.
This forum is not for asking programming related questions.

Moderator: General Moderators

Post Reply
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Versioning

Post 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?
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Re: Versioning

Post 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.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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?
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post 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...;)
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post 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. :)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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.
AngusL
Forum Contributor
Posts: 155
Joined: Fri Aug 20, 2004 4:28 am
Location: Falkirk, Scotland

Post by AngusL »

Only product where I use version numbers really is my operating system (kernel really at this stage, but it sounds good nonetheless :lol:)

Version.Release.Revision.Build

Build increments every time I, er, build. :P 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.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Versioning

Post 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
User avatar
m3mn0n
PHP Evangelist
Posts: 3548
Joined: Tue Aug 13, 2002 3:35 pm
Location: Calgary, Canada

Post 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.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post 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.
User avatar
Buddha443556
Forum Regular
Posts: 873
Joined: Fri Mar 19, 2004 1:51 pm

Post 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.
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post 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 :P

EDIT | And why on earth did I just reply to this old thread? :oops: I blame feyd for linking to it :P
Post Reply