[Zlib-devel] Versioning

[Cosmin Truta]

Hello, again,

Although the zlib versioning scheme that we used so far was working
fine, I would like to express some concerns about it.


The problem is that the version number of a beta does not indicate the
fact that it's indeed un unstable version. If one runs into some archive
named zlib-1.2.0.3, one may think that zlib-1.2.0.3 is probably better
than zlib-1.2.0 and also better than zlib-1.2.0.2, and they're all
stable releases.

The trouble can start in the moment when someone will put a beta into
a retail application or in a bundle, such as a Linux distribution.

We had similar problems in the old days of libpng, when betas were named
by adding letters after the version number: 1.0.5a, 1.0.5b, etc. were
unstable updates to the stable libpng-1.0.5, and so on. But one day
someone packaged an unstable libpng-1.0.N.letter into a Linux
distribution.

We decided in that moment to change the libpng versioning scheme, and
after some discussions, we agreed to use the following scheme:

  libpng-N.N.N or libpng-N.N.N.N are stable releases
  libpng-N.N.N-betaN are beta releases
  libpng-N.N.N-rcN are release candidates

Even the PNG_LIBPNG_VER_STRING macro, the equivalent of ZLIB_VERSION,
has the "beta" string inside. This safeguard was enough, and, as I
recall, we didn't have versioning problems since then.


It is possible to continue like this, to name the betas as zlib-N.N.N.N
and the releases as zlib-N.N.N. It is also possible to start handling
this in a Linux-like manner, where zlib-A.B.C[.D] is a stable release if
B is an even number, and an unstable development version if B is an odd
number. But if there are only numbers in an unstable version, it has to
be written in the FAQ or in another obvious place about this fact.
I consider, however, that carrying the "beta" watermark in ZLIB_VERSION
and in the archive name, is more foolproof.

**

About the upcoming release:
Mark, are you planning to name it zlib-1.2.1?


Best regards,
Cosmin