From owner-freebsd-hackers Thu Sep 9 10:49:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 8A593152EC for ; Thu, 9 Sep 1999 10:49:06 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 11P8Hf-000L0J-00; Thu, 09 Sep 1999 19:46:55 +0200 From: Sheldon Hearn To: nate@mt.sri.com (Nate Williams) Cc: Marcel Moolenaar , Dmitrij Tejblum , hackers@FreeBSD.ORG Subject: Re: 32+ signals and library versions In-reply-to: Your message of "Thu, 09 Sep 1999 10:56:05 CST." <199909091656.KAA03831@mt.sri.com> Date: Thu, 09 Sep 1999 19:46:55 +0200 Message-ID: <80742.936899215@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 09 Sep 1999 10:56:05 CST, Nate Williams wrote: > Yes, we shouldn't version bump every time someone has a whim, ending > up with 10 version bumps/week, but neither should we avoid them > altogether and cause the Linux syndrome of programs refusing to work > because they have the *wrong* version of glibc2.3 (or whatever).... This is starting to sound like what would help is tighter release management. If changes were held back long enough for a single version bump to cover multiple changes, the situation would be improved. Of course, how practical that kind of management is, is another story. One idea I can think of is to keep track of changes to HEAD that really do require a version bump, without actually bumping version. When multiple changes are merged back to RELENG_3 at the same time, the version bump takes place. So you end up reducing the frequency of your bumps. Smoother ride for everyone but the poor bastard who has to track changes more carefully. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message