Michael Weber wrote:
> Is there a reason, why omitting z if zero? Making the version number
> *always* a triple "x.yy.z" is a) more consistent, b) easier to parse
> (you can rely on having three dot-separated fields and c) additionally
> a good break, since version numbers up to now are only pairs like
> "x.yy", so you can just say "Oh, version is not a triple, so it must
> be a GHC from The Dark Ages(tm)" and continue accordingly.
These make the version numbers better for automated processing, but the
numbers serve a dual purpose: they should be easy for people _and_
machines, but people come first. Numbers ending in ".0" are
counterintuitive to me.
> well, I've no _really_ strong arguments against it, but is there any
> good reason I've missed for having anything but numbers (and the dot
> for separation) in a version? It's perfectly sufficient, and I've
> always wondered, why people did sth. like the above... (Remember, now
> an even middle number is indicator for a stable version, so _that_
> particular argument is void now).
I think the reason is, again, human. It's more obvious that it's an
unstable release if there's a keyword like "pre" or "beta" in the
version string. The odd middle number is not that obvious, even when
you know the rule.
> Oh, and might I bring the switch `--numeric-version' (for
> example, emits just "4.09.20000609" on a single line) into scope...
That actually sounds like a good idea to me, as long as the rules to
convert version strings to/from numbers are very solid, and the
relationship is 1:1.
I support Simon Marlow's proposal as it stands, with the possible
addition of the --numeric-version option.
Thanks,
Matt Harden
