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

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.

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

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