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>