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