Date: Thu, 09 Sep 1999 19:46:55 +0200 From: Sheldon Hearn <sheldonh@uunet.co.za> To: nate@mt.sri.com (Nate Williams) Cc: Marcel Moolenaar <marcel@scc.nl>, Dmitrij Tejblum <tejblum@arc.hq.cti.ru>, hackers@FreeBSD.ORG Subject: Re: 32+ signals and library versions Message-ID: <80742.936899215@axl.noc.iafrica.com> In-Reply-To: Your message of "Thu, 09 Sep 1999 10:56:05 CST." <199909091656.KAA03831@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?80742.936899215>