Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Handling version numbers

by djw (Vicar)
on Jul 20, 2001 at 23:45 UTC ( #98513=perlmeditation: print w/replies, xml ) Need Help??

I have started my first "large" project that I am managing on SourceForge.net.
Other than Perl, I have no education or experience in programming so I wanted to ask how people use versioning around here.

Being a linux person, I see most programs come in the form of:
    name-#.#.#.tar.gz

So of course I wanted to use the same format for my program. I started my initial version at 0.3.0 (sounded good - no real reason) and went up from there. I increased the version # depending on how much work/bug fixes went into a release. I am trying to work in the style of "release early and release often" and so some of my updates were small bug-fixes and got an increment of 0.0.1. Some of the other releases that incorporated something new, or made my program work better, got a larger increase like a 0.0.5 increase. Sometimes I was just really happy with what I had changed/added that I bumped up the version number a little farther.

So basically that is how I'm handling it. Really I only have one file that I update and its not all that complex. I'm not in a business atmosphere and I don't have schedules etc for anything.

Now I have heard some things people use to identify their program and that gives their version structure throughout the product life. For example - if the last number is an odd number, that means its a beta. Or if the last number is a 0, then it is a major release.

What are some methodologies used when building your versioning system? Do you use the same system for everything you do? Is there a guideline you like to follow if you can?

Thanks,
djw

Replies are listed 'Best First'.
Re: Handling version numbers
by footpad (Monsignor) on Jul 21, 2001 at 02:49 UTC

    Well, since most of my career has been spent developing for Windows machines (sorry), I've adapted the four-valued version numbers supported by the API. As you might expect, these are:

    • Major Version, which is generally updated after major surgery, significant feature enhancements, or major UI face lifts.

    • Minor Version generally gets incremented after phases adding incremental changes or minor enhancements.

    • Release Number gets incremented for maintenance changes, bug fixes, cosmetic improvements, subtle interface adjustments, and so on. Little stuff.

    • Build Number gets updated each time I compile (Delphi) or perform unit testing (Perl). Generally, this gets incremented a few times a week.

    I say generally for the first two items, because I base my judgement on the amount of work needed to perform the tasks in the phase, the visibility to the project's "users" (end-users or developers using my code), and the significance of the changes that were made. For example, I increased Major Version numbers when I ported my 16-bit applications to 32-bit. Those were visible changes, though the amount of work ranged from trivial to major reconstructive surgery. I may not always increment the major release if the users don't see any real changes or obvious benefit. For example, I recently had to completely rewrite some printing routines that took a few weeks to complete. This was clearly major surgery, however, the only tangible benefit was that reports were more reliable and printed more quickly. So, even though it was a lot of effort and regression testing, I only incrememented the minor release.

    When faced with the latter type of change, I might consider boosting a .0 to a .5 release if it adds something less than "major" changes.

    You mentioned that you don't use schedules. Well, that's fine for smaller and personal projects, but I've noticed that it at least helps to have a roadmap sketched out. It doesn't need to be terribly formal or even exact, but we tend to design ambitiously when we start dreaming up projects. (Well, okay, I do that; I suspect others do, too.) If I sketch out the major features of the system and then break those out into sections of code that need to be completed first, I not only get the start of a task list and implementation plan, I also start getting ideas about how much time things are actually going to take. I can also see if, for example, Feature A would be a lot easier to do if Feature C was built first. It helps me know how to proceed with the proejct.

    This relates because I can now start getting an idea for what I can accomplish within a given time frame. Once I know that, I can begin to map out a release schedule that focuses my time a little better. If I release version 1.0 containing only Feature C, for example, I can follow it up within short order with 1.1, 1.5, or even 2.0--depending on the visibility, scope, and benefit of Features A and B.

    I believe you should always have a schedule, if only to challenge yourself and improve your performance skills. (I've also found this helps me stay more focused on the project and not get distracted quite so easily.

    --f

Re: Handling version numbers
by perigeeV (Hermit) on Jul 21, 2001 at 02:06 UTC
    Eric Raymond's Software Release Practice HOWTO has just oodles of information. You would not do badly to follow any of the practices outlined.

    Oh, and don't forget to throw in an Easter egg. What ever happened to the joy of finding a tasty undocumented feature?! No one does that any more.

Re: Handling version numbers
by John M. Dlugosz (Monsignor) on Jul 21, 2001 at 02:34 UTC
    As an aside, the v-string literal in Perl doesn't like leading zeros; e.g. v0.09 thinks that the 09 part is octal! Since the comparisons of v-strings work part-wise, there is no longer a need to call it 09 just so it sorts less than 10.

    A while back I wrote a compare function that took all kinds of stuff in a version string, and compared each part according to what it looked like. So you could have '3.0b' for example. But using v-strings throughout Perl for $VERSION etc., we need to stick with plain numbers.

    As for different ideas, here at work we have a major release called an "Iteration" and within that possibly more "Revisions". Once we had a patch, so that gives three numbers: i3r1p2, for example. Or v3.1.2 to use more standard forms.

    In some of my C++ freeware, I have versions released as formal releases called "Public Build", so you have for example pb5. No subversions or anything--each time the formal release process is performed, the number is incremented. That's simpler than keeping track of various levels and what they mean, isn't it?

    For continuing work, I use a trailing + symbol. So version pb5+3 is three informal releases beyond pb5. If I wanted to note individual builds, that could be a third number.

    So what that boils down to is that the internal releases are a deeper number than the formal releases, as opposed to using odd/even or different ranges. Logically, it amounts to the same thing: formal release further increases the number, new development increases that, and you can tell whether a version is formal or internal if you know that only certain numbers can be formal because they are snapped to a grid, so to speak.

    I think that's the fundimental concept set that works for lots of people.

    You should also work within people's intuition that changes to less-significant positions means less significant changes.

    For my backup utility script, I don't distinguish between formal and internal work. It's small and simple so I generally don't stop until it's stable again.

    I suppose a status indicator near the $VERSION indicator would be a OK idea, in general. State whether it's formal, beta, private, etc.

    —John

Re: Handling version numbers
by japhy (Canon) on Jul 21, 2001 at 00:25 UTC
    I usually use a single-decimal place versioning system, major.minor. The minor is reserved for bug fixes and added functionality strongly related to existing functionality. major is reserved for rewrites, or stunningly new functionality.

    _____________________________________________________
    Jeff japhy Pinyan: Perl, regex, and perl hacker.
    s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

Re: Handling version numbers
by Anonymous Monk on Jul 21, 2001 at 01:56 UTC
    I too use a major.minor type version numbering scheme. I increment major numbers when I make a non-backwards compatible change and minor numbers for everything else. (and of course, I also reset the minor to 0 when ever the major changes)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://98513]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (11)
As of 2018-11-14 15:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My code is most likely broken because:
















    Results (173 votes). Check out past polls.

    Notices?