This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Re:There are several points in this article

Posted by: Anonymous Coward on June 13, 2005 12:18 AM
Well, except that it's already clear that it
is not actually a decimal point, just as soon as
you see two of them in the same number.




Although I partially agree with the second idea
here, I disagree with the first...



Non-integer version numbers started off using
the very typical meaning of a decimal point...
Version 2 meant the second major complete
release, version 3 meant the third, and if the
author made a big but not full-version-worthy
improvement midway, they would use 2.5 to indicate
that... A version half-way between 2 and 3.



That extended to include more-or-less regular
updates, such as 2.1, 2.2, 2.3, and so on. Still
following decimal-point rules.



But then, somewhere along the way, an
author got to the version after 2.9, but didn't
have something he could call 3.0. So, we got
either "2.91", in keeping with decimal rules,
or "2.10", probably cute at first, but it opened
the floodgates for the mess we have now.



Next, we had the addition of bugfixes and
patch-levels, that added on another decimal
point... 2.4.1, the first patch to 2.4. Still,
though, it basically followed decimal rules,
and violating them only confuses people.





Personally, I prefer a scheme whereby it will
always monotonically increase, and has a well
defined number that takes no consideration of
progress to figure out - The compile date.
Now, that still leaves some ambiguity in the
open source world when you might have a dozen
project forkes, but I see no neat way to deal
with that other than to give the forks different
names, and let the user suffer figuring out which
fork they want. But once they know that,
they can instantly identify the most recent
version.



And as for "beta" versions - A word of advice to
my fellow coders - STOP RELEASING THEM!!! Yes,
you can give a few freinds a copy to test, but
do NOT release known-unstable code to the general
public. If such a beta somehow slips out, just
refuse to acknowledge it - Answer any questions
about it with nothing more than a link to the
most recent "real" version.



And that, I think, explains most of the problems
with versioning - People need to stop releasing
versions that should never have seen the light
of day. If you know for certain that you'll
need to release an update in a month to fix all
the known bugs - Don't release anything
for another month!

#

Return to Decline and fall of the version number