Current details for split-inventory work

[Jari Aalto]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> 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.

Any versioning scheme that increases is fine. For packagers of bzr the
ideal is the logical sort(1) order, which means that these, although
nice for ordinary people, won't "sort" nicely:

  1.1
  1.10

So, whatever is used, the 2 number versioning would be preferrable:

  2.01
  2.02
  ..
  2.20

Using the date based releases automatically solves this. I like this
because it is possible to immediately see the release date. Think, when
was 1.0 released? or 1.1? Person complaining that his bzr 1.x "does not
work", cannot see that his bzr is old. With date based versions it'd be
obvious:

  YYYYMMDD

About X.Y.Z.ZZ releases, people mostly associate that to Kernel workflow,
which is logical. For Bzr maybe something like:

   2.x      For major changes; new repository layout etc
   2.x.y    For minor changes, improvements bug fixes
   2.x.y.z  "Point releases", or current "rc" series.

Btw, the "rc*" naming is nightmare for automatic watching of new
releases. With pure "sort" naming, a bot could examine web page and send
mail when new release is available.

Jari