Date: Wed, 29 Sep 2004 20:36:45 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-current@freebsd.org Subject: Re: HEADS-UP: Library version number bumps Message-ID: <Pine.GSO.4.43.0409292016080.16453-100000@sea.ntplx.net> In-Reply-To: <20040929.174914.05878370.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 29 Sep 2004, M. Warner Losh wrote: > In message: <Pine.GSO.4.43.0409291006430.13426-100000@sea.ntplx.net> > Daniel Eischen <deischen@freebsd.org> writes: > : This has been mentioned before, but when breaking (or potentially > : breaking) ABI, can we bump the version numbers to libfoo.YYYYMMDD? > : Once release comes, we can move them back to SHLIB_MAJOR + 1 (or > : even decide to keep them at SHLIB_MAJOR if ABI wasn't really broken). > : This helps folks running HEAD so they can update their ports over time. > > In a lot of respects I like this idea. However, the unanswered > question would be how to implement it. The bumps are easy to do (the > version number is basically meaningless), but frequeny bumps have > issues as well. Laying those aside for the moment, my concern is how > do we do the 'one release comes' part there. How do we know if they > are binary compatible or not? Wouldn't this tend to encourage people > to make binary incompatible libraryes? It doesn't solve the current problem of knowing if changes break ABI. It is also still up to the committers to both avoid introducing any uncessary ABI breakages and to review other committers' changes. I suppose 'Once release comes' is when we're getting ready for release and the re@ team lays the tag and freezes the branch. At that point, you move the version numbers back in both the branch and HEAD. re@ comes out and says "Try to avoid any major changes to HEAD until after release" which implies "no more shared library ABI changes". I know there will be some ABI changes in 6.0, libc for sure. If we go directly from libc.so.5 to libc.so.6 after the first ABI change, that hoses -current folks when the next libc ABI change hits the tree and you don't bump the version number again. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0409292016080.16453-100000>