Re: Seeking thoughts on version numbers in modules

[tye]

1.3.1 isn't going to fly since v-strings are deprecated. I number modules as j.nn_ww: j=maJor revision, something that probably involves non-trivial interface changes; nn=miNor revision, which should include a batch of bug fixes and/or feature enhancements; ww=Whatever, which I increment for any trivial reason such as when I copy the module somewhere to test on a new platform or even after I've made trivial changes but have stopped working on it for a while even though I don't plan on making a release any time soon.

Update: Note that with this scheme I have mostly abandoned the idea of having "pretty" version numbers. I once strived to have version 1.02 follow version 1.01 and have the first really stable version of the module be version 1.00 or 1.01 (and have beta versions marked with a "b" or some other convention) etc. But I've come to decide that "pretty" just ain't worth much.

Version numbers should be simple and sort easily. And if two copies of a module are different then they really need to have different version numbers. So a big point is that the version number needs to increment at the drop of a hat, that is, whenever the module gets copied anywhere, even if (I think) I'm the only one who will ever see that copy.

A lesser point is that I've never been blessed with a community of module users that I would call a crack module testing team. So I never reach some point where I declare a module "out of beta". I release modules when I have something to release. If no bugs reports or requests come in, then I'm not going to make a new release with an announcement of "I haven't heard any complaints so I'm changing the version number and it is no longer beta". I'm sure such would just lead to needing a new release almost immediately. (:

Note that I also avoid trailing zeros in version numbers so there is no 1.19_00 and after 1.19_09 is 1.19_11.