Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Feb 2001 11:14:38 +0000
From:      Paul Richards <paul@originative.co.uk>
To:        freebsd-current@FreeBSD.ORG
Subject:   Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Message-ID:  <3A8BBA1E.A11923FB@originative.co.uk>
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> <20010215021353.D66813@dragon.nuxi.com>

next in thread | previous in thread | raw e-mail | index | archive | help
David O'Brien wrote:
> 
 
> 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.

Yes, that was true. The way we used to do it didn't address all the
problems I'm alluding to either but I felt we had more versioning before
than we do now. Regardless of that the issues are important enough that
I think we should discuss them.

There are in my mind two issues:

1) Being able to have the system continue working when a significant
interface change occurs.
2) Being able to identify a specific version of a library on a system in
order to determine whether it's a rogue version for a particular
application.

The former I accept works fine now as long as you can take the pain of
current. An asthetic requirement to have a nice library number is
counter-productive though when it screws the development team so
completely that the system is unusable for a week. While developers
should accept that they must occasionally suffer considerable pain when
running -current it's foolish to not consider alternative methods of
working when we run into a problem that causes the project to come to a
grinding halt.

Most of us don't have rooms full of development boxes, we have all our
day to day applications on our development box and having to rebuild it
completely is something we accept we may have to do on occasion but it's
something we should try and avoid having to happen because it's so
wasteful of everyone's time and energy. This library version problem is
a non-problem from a technological perspective, it's only a problem from
a policy perspective and it's a policy that's based entirely on asthetic
requirements.

I don't want to see library versions get into the hundreds (unless we
adopt that as a convention i.e. 5xx) because we're bumping them all the
time but at the same time, if one is necessary then it's necessary, even
if it's current. Commercial vendors will skip version numbers in their
public releases if their internal development required more than one
bump.

I don't think the attempt to make the major number bump once per release
is a sensible goal. If we have to bump a major number on the stable
branch (god forbid, but it may happen one day) then we'll have to
deviate from that policy because it'll clash with the version number of
-current and therefore I think the policy is flawed because it doesn't
consider all the possible scenarios we might have to deal with.

The second issue is probably not related to bumping the library version,
since I accept your point that we didn't bump major or minor numbers for
every change to the library. I think some way of identifying a build of
a library would be a good thing though and perhaps we should discuss
adding a "properties" field to libraries so we can identify which
specific version of a library is installed.

Paul.


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?3A8BBA1E.A11923FB>