Date: Tue, 28 Mar 1995 13:44:53 -0600 From: rkw@dataplex.net (Richard Wackerbarth) To: Paul Richards <paul@isl.cf.ac.uk> Cc: current@FreeBSD.org Subject: Re: shared library versioning Message-ID: <v02110104ab9e1496c531@[199.183.109.242]>
next in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02110104ab9e1496c531>