versioning

[Ulrich Drepper <drepper at redhat dot com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The reason I've stayed with version 2.3.2 for so long is that, as the
last release cycle clearly showed, it does not make much sense to put
out test releases, wait, and then make a release.  Nobody[*] tests it
anyway.  So if the code builds for the people on this list, it is good.
 And it should always build, maybe one or two days breakage, but that
has been a rare occasion.

Therefore I want to go to a time-based version numbering.  This will
help to pinpoint the base version a bug reporter is using easier.  The
sub-release number should perhaps be bumped every week, maybe every two
week.  I.e., we'd have 2.3.3 next, a week later 2.3.4.  I stepping to
2.4 is a bit too irritating.

This will lead to high numbers, sure.  But we can also say that after
2.3.N, for N == 51 or so, we automatically go to 2.4.  This will give a
predictable schedule, especially if some interface changes are
associated with a minor version jump (like dropping LT in 2.4).

I think this will work fine since I don't see any big changes on the
horizon.  We are mainly in maintenance mode, with optimizations and
adjustment for recent additions/changes to specifications.  None of this
requires a separate development tree as we used to have in the past.


If somebody sees a reason why this shouldn't be done, speak up now.
Otherwise I'll put the mechanisms in place to get this process going.


[*] Well, one or two people do, but this is insignificant given the
number of users.

- -- 
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/yEXf2ijCOnn/RHQRAtW8AJ9a3stIcaG5c6nwHq04La0Ux1XObgCfcS3Q
wGIuKoHdDeWvmDx6WvK9TRM=
=QGbk
-----END PGP SIGNATURE-----