bzr version numbers

[Stephen J. Turnbull]

Colin D Bennett writes:

 > I certainly don't find 1.10 vs 1.2 confusing:
 >    "one point ten"  versus  "one point two"
 > seems straightforward.

It is, but that's because you've thought about the release process.
To a person who's not done that, it's not obvious that 1.10 != 1.1,
and in fact I've seen projects where they've just partitioned an
6-decimal float n.3-3 and use %f (not %.6f!) to print the version
number.  (Conjecture from the behavior of version numbers.)

 > > Going 1.7, 1.8, 1.9 feels a bit like it's creeping along, whereas
 > > making them date-based makes a virtual of reliability.

Nice Freudian typo!  That's *precisely* how I think of date-based
versioning (see below).

Reminds me of the days when the FSF would one-up Lucid by making their
first beta release have a higher minor number than Lucid's current
release.  It's the size of the diff of NEWS that matters, not the size
of the version number.

 > IMHO it doesn't matter if the numbers are based on dates or simply a
 > monotonically increasing counter; as long as they are increasing, I'll
 > be just as happy.

My issue would be more along the lines that "these are minor version
bumps" is untrue.  Many users report issues in both directions because
of the incessant tweaking of incompatible repo formats.  Yeah Yeah
Yeah I've heard the Greek chorus "But they're all usable by later
versions, But They're All Usable By Later Versions, BUT THEY'RE ALL
USABLE BY LATER VERSIONS" in four-part harmony, which is true but
beside the point to a user who is facing warning and admonitions which
she doesn't understand and doesn't want or need to understand.  A
major version bump at least when the default changes might reflect the
user's perceived reality better.  (I'm not sure of that.)

 > Numbers are simple, concise, and they intuitively and instantly
 > indicate ordering.

Unfortunately, they don't always indicate ordering intuitively, FSVO
"reader".  Also, numbers often have cardinal properties, and these are
partly intuited from context and partly defined by project policy.

It is however easy to specify what properties of numbers are relevant,
and to automate the ordering parts.

 > > It's annoying that deprecations and format names need the version
 > > coded into the patch when they start, even though it's hard to tell
 > > what precise release they'll land in.

I think this indicates a process problem.  I've never seen this
complaint on the Python lists, and they've been using this mechanism
for many years by now.  I suspect the reason why this doesn't happen
is that Python has an (informal) process for setting milestones for a
minor release, and that minor releases take place many months apart.

The Bazaar process currently seems to be in tweak-and-release mode,
which works pretty darn well for accretion of features (including the
repo format changes I complained of above; don't get me wrong, that is
mostly a cosmetic issue, but cosmetics do matter as that multi-billion-
dollar industry will happily attest).  But it's not very good for
backward-incompatible changes like removal of APIs, which probably
should occur infrequently and in batches.

Ask Barry Warsaw how he thinks Python's 3-place version number scheme
would adapt to a process with monthly releases at the micro version
level (bugfixes only).  (This is something he's dreaming about, I
think.)  Betcha he'll say "without change".

However, that policy wouldn't work for Bazaar's current process as I
understand it.  What might work would be a system where major version
is bumped for user-visible backward-incompatible change (without a
plausible workaround), minor version for implementation changes that
can be hidden from users but not from plugins (API removal), and micro
version would allow both additional features and API deprecations.
There would be no "bugfix-only" release level, as y'all seem to be
getting along fine without one at present.

 > > Let's not bikeshed this; everyone has opinions from random
 > > projects.

This is *not* painting the bikeshed.  Version numbers are the public
indicator of the progress of your process.

 > I really don't care too much, but it just seems like date-based
 > version numbers are the latest fad to me.

 +1.  Date-based processes are important, but version numbers should
say something about quality progress.  Time passes, by definition, and
                 that tells us nothing about quality.

Steve