Re: Versions Thought

in reply to Versions Thought

I always start with '0.01' and go up from there. Then, generally, I have a major API/featureset upgrade. That's when I roll over the numbers to 1.00, then go up from there.

Only once have I ever released a module at 1.00 and that was Class::Lazyload. I did it that way because the featureset was so limited and the testcases mostly obvious, so stvn and I could inspect and figure we'd covered almost everything.

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re: Versions Thought

Replies are listed 'Best First'.
Re^2: Versions Thought by pileofrogs (Priest) on Mar 13, 2006 at 22:47 UTC
I think you might be exactly my target audience for this meditation. Your version system is an example of one that contains no data about the pre-release or production ready status of your modules. Anyone who assumes version numbers encode that information could be mislead by your system. Instead of starting at 0 and moving to 1 when you make your first big API/featureset changes, you could start at 1, and lose absolutely NO data, but gain some clarity (or more to the point, remove ambiguity). Or, said from the reverse direction, when you hit major version 1, you may have been giving the false impression that you were declairing your module production-ready. Probably the best idea would be to start at 0, and then magically jump to 1 when you feel like your module is production ready, even when there aren't any major API/featureset changes. Then increment the major version number for every major API/featureset change after that.	[reply]

Replies are listed 'Best First'.

Re^2: Versions Thought
by pileofrogs (Priest) on Mar 13, 2006 at 22:47 UTC

I think you might be exactly my target audience for this meditation.

Your version system is an example of one that contains no data about the pre-release or production ready status of your modules. Anyone who assumes version numbers encode that information could be mislead by your system.

Instead of starting at 0 and moving to 1 when you make your first big API/featureset changes, you could start at 1, and lose absolutely NO data, but gain some clarity (or more to the point, remove ambiguity). Or, said from the reverse direction, when you hit major version 1, you may have been giving the false impression that you were declairing your module production-ready.

Probably the best idea would be to start at 0, and then magically jump to 1 when you feel like your module is production ready, even when there aren't any major API/featureset changes. Then increment the major version number for every major API/featureset change after that.

[reply]

In Section Meditations