To Patch or Not to Patch

[Cliff Nichols]

This has ALWAYS been a sore point with me, and it has reared its ugly head again the last few days.

My Unique area (small market compared to M$) but HUGE to me, seem to be running into what might be a "BUG" to them (but what really is a combination of errors to their particular view) that culminate what even I would call a "BUG"(AKA: Soooooo.....I made a mistake )

I have a work-around (for the time being), and have been working on a newer version to correct my mistake(s) of the past, but lately I am getting more and more users that somehow hit this "BUG" and it is really cutting into my development time to explain what is already documented "IF this should happen then do THIS"

From other mistakes of the past, I always came up with a new version to replace the old version. (even if it meant using up version numbers to fix a minor detail).

My question is, to fix a problem, is it better to call it a "Patch" (even though its a complete replacement for the version) or to call it a version?

usually my stance is if changes are made, I make it a new version that offers more options, but if it is something I am working on already to offer an option, but have to push out the door and only allow options that are tested and the fix to the problem. Now I am presented with an interrupt of a problem while in the midst of adding options.

Should I post as a Patch? (and ignore that there are improvements? or post as a patch and rip out my improvements, or ????)

Seeing how I am 1 lone programmer, its awfully hard to code, take a phone call, code, find an idea, develop it, ooops another call for something stupid, figure out where I was, code....ooops another call....hey what do you know??? I made a mistake somewhere???....work on a fix....ooops, what the heck do I post? (a patch, a version or what??))

and remember my end users are typically NOTTTTT programmers....so if not perfect they tend to get onry

[Fred Buffington]

I always looked at a patch as something that was run one time to modify an existing program (not a workaround). I.e. It replaced a portion of already existing code with something new. This is usually difficult unless the patch replaces the correct portion of code with something no larger than the original code. Perhaps the easiest example being changing a zero to one in one place or another, so my vote would be for calling it a version and having a comment or history of what it does unless it is that simple.

[Scott Slater]

There is no exact way of doing this, but typically the version number on the left side of the (first) decimal is the MAJOR and the remaining stuff is the MINOR and subversion etc...

Any minor fixes and small additions would be an "Update" and would only justify the MINOR part of the version to be incremented (that to the right of the first decimal).

If you add substantial new features to your program as well as bug fixes etc., then it is an "Upgrade" so you would increment the (MAJOR) version to the next value and start the MINOR(s) at zero.

[Michael Mattias]

I have two rules I follow..

1. No executable (EXE or DLL) goes out without a version resource, ever.
2. If something - ANYTHING - changes, the version (X.Y.Z) is updated; thou shalt never ship different software with the same version number.

I use the major.minor.build format as Mr. Slater suggests.

MCM