From owner-freebsd-hackers Thu Sep 9 18:42:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.utexas.edu (wb3-a.mail.utexas.edu [128.83.126.138]) by hub.freebsd.org (Postfix) with SMTP id D37DD154AA for ; Thu, 9 Sep 1999 18:42:47 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: (qmail 8926 invoked by uid 0); 10 Sep 1999 01:42:35 -0000 Received: from dial-109-13.ots.utexas.edu (HELO nomad.dataplex.net) (128.83.177.157) by umbs-smtp-3 with SMTP; 10 Sep 1999 01:42:35 -0000 From: Richard Wackerbarth To: nate@mt.sri.com Subject: Re: 32+ signals and library versions Date: Thu, 9 Sep 1999 20:16:49 -0500 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain References: <199909091854.MAA04905@mt.sri.com> Cc: hackers@freebsd.org MIME-Version: 1.0 Message-Id: <99090920414202.01833@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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