Date: Sun, 13 Aug 2006 14:50:22 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: sgk@troutmask.apl.washington.edu Cc: deischen@freebsd.org, freebsd-current@freebsd.org, thompsa@freebsd.org, fullermd@over-yonder.net Subject: Re: Where is thr_getscheduler Message-ID: <20060813.145022.-1398303152.imp@bsdimp.com> In-Reply-To: <20060802165604.GA970@troutmask.apl.washington.edu> References: <20060801213803.GB9583@troutmask.apl.washington.edu> <20060802144255.GU69505@over-yonder.net> <20060802165604.GA970@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20060802165604.GA970@troutmask.apl.washington.edu>
Steve Kargl <sgk@troutmask.apl.washington.edu> writes:
: On Wed, Aug 02, 2006 at 09:42:55AM -0500, Matthew D. Fuller wrote:
: > On Tue, Aug 01, 2006 at 02:38:03PM -0700 I heard the voice of
: > Steve Kargl, and lo! it spake thus:
: > >
: > > If UPDATING had a proper notice,
: >
: > If UPDATING had a notice every time a {library,program} in 7 did
: > something that wasn't supported by 6 (for various values of 7 and 6),
: > it would be a very, very long and very boring file.
: >
:
: Sigh. We go through this every time someone bumps libc's
: version number without bumping the version numbers of
: all other libraries. There is significant difference
: bewteen changing libgpib.so version number and changing
: libc.so version number. Changeing libc's version number
: should have been noted in UPDATING.
Yes. And we shouldn't be bumping libc in current unless we also turn
symbol versioning on at the same time...
: The version number of libthr should have been bumped
: when David Xu committed his change.
:
: Last time I checked there were several integers between 2 and
: INT_MAX. Is there some sort of shortage of integers at
: freebsd.org that prevents bumping libthr.so.2 to libthr.so.3?
We do try to only bump one per major release...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060813.145022.-1398303152.imp>