This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: versioning


Ulrich Drepper <drepper@redhat.com> writes:

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

Yes, we need more releases.  Distributions, e.g. both Red Hat and SuSE
use some CVS version of the day and which shows that going back to the
latest release is not the right thing to do.

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

I would still do some prominent official releases.  So, e.g. 2.4.0
could be an official release with announcement, tarball etc.
Everything else would be development releases.  We just make an
official release either time-driven, e.g. every half year, or feature
driven.

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

In general I would say go ahead - but let's discuss the "official
release" issue first.


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


Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

Attachment: pgp00000.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]