Brave new (1.0) world.

[Andrew Whitworth]

On Thu, Feb 19, 2009 at 3:56 PM, chromatic <chromatic at wgz.org> wrote:
> That's why I like the date-based scheme.
>
> Alternately, we could skip all of the debates about what's major and minor and
> how many real numbers there are between 1.0 and 1.5 or 1.5 and 2.0 and say:
>
>        July            1.5(.0)
>                        1.5.1
>                        1.5.2
>                        1.5.3
>                        1.5.4
>                        1.5.5
>        January 2.0(.0)
>
> That satisfies the property that version numbers should increase and it gives
> the numerologists slightly less ammunition to tell us what the spirits of our
> ancestors are trying to tell us through tea leaves and tattooed chicken bones.

I'm not particularly happy with any system that is totally arbitrary,
be it an arbitrary declaration of a major/minor update to reduce
numbering conflicts or a arbitrary decision that we only use x.5.y or
x.0.y in our version numbers. The engineer in me says that we're
wasting a lot of in-the-middle numbers with that, even if numbers are
very cheap.

> Note also that the push-to-1.0 approach came about because Allison said "Screw
> this milestone approach with its major features; let's just set a hard
> deadline and start throwing out non-critical features."  I'd hate to let the
> infatuation with what's major and what's not creep back in and siphon away
> this great momentum we seem to keep building.

I like momentum, and ever-embiggening numbers is a perfectly cromulent
way to keep it going. Just as stupid it is that the Linux kernel
version number string is about 50% "stuff that probably wont ever get
changed", it's also going to look pretty lousy for us to take a random
string of numbers that looks like we pulled them out of a hat. I would
much rather prefer a version string that meant something real, like
2009r1 or r1.1 (... r1.12, r2.0) Then numbers that are completely
arbitrary and that we try to stretch to fit what a real calendar looks
like. The former would make our deprecation policy much easier: We
don't support any version where the year in the version number doesn't
match the year you see on a current calendar.

--Andrew Whitworth