Re: Symbol versioning conventions

On Sun, 26 Aug 2007, M. Warner Losh wrote:

> In message: <Pine.GSO.4.64.0708261240070.23191_at_sea.ntplx.net>
>            Daniel Eischen <deischen_at_freebsd.org> writes:
> : On Sun, 26 Aug 2007, Yar Tikhiy wrote:
> : >
> : > But, anyway, there are at least three people in the project who
> : > misundertood the intended role of symbol versioning.  Besides yours
> : > truly, a humble developer, there are a core team member and a release
> : > engineer among them.  This may be a sign that some decisions regarding
> : > symbol versioning, which is a rather central feature for developers
> : > and code contributors, haven't had enough exposure.  Perhaps we've
> : > just missed some important discussions on the lists, but symbol
> : > versioning is a long-term feature and as such it deserves a document
> : > describing in detail how to use it in our project.
> :
> : I've think I've stated in replies to commit mail that symbol versioning
> : isn't meant as a crutch to aid -current developers, but that is neither
> : written down or documented and was probably over a year ago.
>
> You never answered my point: The release engineer gets to decide when
> the ABI is frozen.  Maybe it already is and this use isn't a crutch.

There can be only one ABI or version in a release.  Having multiple
_new_ versions between releases implies you are using the intermediate
versions as a crutch ;-)  In this case, it may be a little different
because we haven't yet released anything with symbol versioning.

The other thing to remember is that we did bump library versions,
so any ABI changes are for free (excluding the upgrade pains typically
felt by -current developers).  If you keep the old FTS and compat
functions, you are maintaining them and keeping the old files in the
tree when they've never ever seen a release - there is no point
in maintaining them _other_ than to aid -current developers.  They
certainly don't help applications built in 5.x or 6.x.

-- 
DE