public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
From: Andreas Jaeger <aj@suse.de>
To: Ulrich Drepper <drepper@redhat.com>
Cc: Glibc hackers <libc-hacker@sources.redhat.com>
Subject: Re: versioning
Date: Sat, 29 Nov 2003 17:58:00 -0000	[thread overview]
Message-ID: <u8ad6f9wza.fsf@gromit.moeb> (raw)
In-Reply-To: <3FC845DE.1030905@redhat.com> (Ulrich Drepper's message of "Fri, 28 Nov 2003 23:08:14 -0800")

[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]

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 #2: Type: application/pgp-signature, Size: 188 bytes --]

  reply	other threads:[~2003-11-29 12:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-29 12:41 versioning Ulrich Drepper
2003-11-29 17:58 ` Andreas Jaeger [this message]
2003-11-29 18:21   ` versioning Ulrich Drepper
2003-11-29 18:55     ` versioning Andreas Jaeger
2003-11-30 19:05       ` versioning Ulrich Drepper
2003-12-02  0:02 ` versioning Jeff Bailey
2003-12-03  1:19 ` versioning Roland McGrath
2003-12-07 10:47   ` versioning Andreas Jaeger
2004-01-19  3:31     ` versioning Roland McGrath

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=u8ad6f9wza.fsf@gromit.moeb \
    --to=aj@suse.de \
    --cc=drepper@redhat.com \
    --cc=libc-hacker@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).