Date: Thu, 9 Sep 1999 20:16:49 -0500 From: Richard Wackerbarth <rkw@dataplex.net> To: nate@mt.sri.com Cc: hackers@freebsd.org Subject: Re: 32+ signals and library versions Message-ID: <99090920414202.01833@nomad.dataplex.net> References: <199909091854.MAA04905@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 09 Sep 1999, Nate Williams wrote: > > I'm more tempted to revert to the major/minor versioning. > > ELF has no minor revision number (IMO a mistake, but it's not my call). I agree that it is a mistake. However, if you think of "major" changes as different libraries, it does make sense. We then have libxxx.so and libxxx2.so as the "major" versions and treat the ELF revision number as the minor number. In either case, I think it is a good policy to makei, f needed, an extra increment to the major number and reset the minor number to zero when we actually release a new system. To avoid too many "bumps" of the major number, we could use the stopgap encoding scheme of jumping the revision to the next multiple of 1000 to hide major revisions during the development phase. Thus, libxxx4.so.0 is released. It is patched to libxxx4.so.1, etc. If, during development, we need a major bump, we could use libxxx4.so.1000 as a standin for libxxx5. Finally, at the time of release, libxxx4.so.7042 could be renamed to libxxx5.so.0 and recompiled for release purposes. The only drawback is that users of development versions would have to watch for and manually handle versioning. I'm not sure which I consider worse, the "run away" version numbers or the failure of the system to recognize the linking error. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99090920414202.01833>