From owner-freebsd-current Tue Mar 28 11:46:14 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA25307 for current-outgoing; Tue, 28 Mar 1995 11:46:14 -0800 Received: from catfish.dataplex.net ([199.183.109.243]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA25297 for ; Tue, 28 Mar 1995 11:46:12 -0800 Received: from [199.183.109.242] (cod [199.183.109.242]) by catfish.dataplex.net (8.6.9/8.6.9) with SMTP id NAA19104; Tue, 28 Mar 1995 13:44:51 -0600 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Mar 1995 13:44:53 -0600 To: Paul Richards From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: shared library versioning Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >> Well, all that's really needed is a file (I propose >> /usr/share/misc/shlib-numbers) which lists the shared-libraries and >> minor numbers used in each release. I will do this today if somebody >> doesn't beat me to it. > >I'm not sure I like that idea, since people will forget to either check the >file or keep it up to date. > >I'd prefer some comment in the Makefile that flags that the library beens >bumped and then have a script which runs through the tree removing these >comments as part of the release process so they're clean at the start of the >next release. Actually, this COULD be automatic. As I see it, any change to the libraries that requires a version number change is a reflaction of a change in the header files. Therefore a make rule than "library version cookie" depends on "headers", would generate the proper increment. The only problem that I see is that my own local version numbers might get bumped numerous times between releases. To address that, either I would have to manually rebuild my executables after a release or we need some sort of major.minor.sub numbering scheme which allows us to "jump" to the next minor number with an actual release. These would be easy to find... If the sub number is not zero, we need to bump the minor number. IMHO, if we were to use such a scheme, the minor number should either stay the same (if nothing changed) or it should match the release number that includes the change. ---- Richard Wackerbarth rkw@dataplex.net