Date: Wed, 2 Aug 2006 09:56:04 -0700 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: "Matthew D. Fuller" <fullermd@over-yonder.net> Cc: Daniel Eischen <deischen@freebsd.org>, freebsd-current@freebsd.org, Andrew Thompson <thompsa@freebsd.org> Subject: Re: Where is thr_getscheduler Message-ID: <20060802165604.GA970@troutmask.apl.washington.edu> In-Reply-To: <20060802144255.GU69505@over-yonder.net> References: <20060801204501.GA19647@troutmask.apl.washington.edu> <Pine.GSO.4.64.0608011657040.1810@sea.ntplx.net> <20060801211657.GA29737@troutmask.apl.washington.edu> <20060801212742.GB13841@heff.fud.org.nz> <20060801213803.GB9583@troutmask.apl.washington.edu> <20060802144255.GU69505@over-yonder.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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?
--
Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060802165604.GA970>