Date: Thu, 15 Feb 2001 02:13:53 -0800 From: "David O'Brien" <TrimYourCc@NUXI.com> To: Paul Richards <paul@originative.co.uk> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Patch for FILE problems (was Re: -CURRENT is bad for me...) Message-ID: <20010215021353.D66813@dragon.nuxi.com> In-Reply-To: <3A89D5BF.D46B8FCC@originative.co.uk>; from paul@originative.co.uk on Wed, Feb 14, 2001 at 12:47:59AM %2B0000 References: <200102130120.f1D1KpU56194@mobile.wemm.org> <200102130131.f1D1VrW33790@harmony.village.org> <xzplmrbmk94.fsf@flood.ping.uio.no> <3A895FA0.25EBC727@originative.co.uk> <20010213131802.B79651@dragon.nuxi.com> <3A89D5BF.D46B8FCC@originative.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 14, 2001 at 12:47:59AM +0000, Paul Richards wrote:
> Instead what we have now is libxyz.so.3 and libxyz.so.3 which are
> different from each other.
No different than two libxyz.so.3.1 and libxyz.so.3.1 could be (a.out days).
(well not entirely true, but in the a.out days, one could make a major
change in the functionality of a lib routine w/o even a minor bump)
If two libxyz.so.3 and libxyz.so.3 are incompatible, then a major shared
version bump wasn't done when it should have been.
> When you login to a strange machine and you're trying to diagnose a
> problem there's no way to know whether the libc they've got installed
> is of version X or version Y because there's nothing to tell you what
> sources libc.so.Z was built from, it could be the .Z version with the X
> fixes or the Y fixes.
When we had minor version numbers you still didnt' know if the X fixes or
Y fixes were in it.
> You've missed the point I was trying to make. Our reluctance to bump
> what we perceive to be a major number is hampering our ability to
> differentiate between different versions.
We aren't reluctant to bump in -STABLE if there is a need for it.
The reluctance is in -CURRENT where we bump once and let that cover all
the incompatibilities. We don't put our released version users thru the
hoops we are willing to for the development version users.
> We could just as easily use a minor numbering scheme
> with Elf to indicate that a version change has occured but not an
> interface change.
We only bumped due to interface changes in the .MAJOR.MINOR days. The
difference is *adding* an interface today does in cause a bump. In the
.MAJOR.MINOR days it would require a bump the MINOR number. In both
days, an incompatible change in an existing interface require(s)(ed) a
MAJOR bump.
--
-- David (obrien@FreeBSD.org)
GNU is Not Unix / Linux Is Not UniX
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010215021353.D66813>