cvs commit: src/lib/libc Versions.def

[Daniel Eischen]

On Tue, 18 Dec 2007, Alfred Perlstein wrote:

> * Daniel Eischen <deischen at freebsd.org> [071217 17:42] wrote:
>> On Mon, 17 Dec 2007, John Baldwin wrote:
>>
>>> On Friday 14 December 2007 03:49:07 pm Daniel Eischen wrote:
>>>> deischen    2007-12-14 20:49:07 UTC
>>>>
>>>>  FreeBSD src repository
>>>>
>>>>  Modified files:
>>>>    lib/libc             Versions.def
>>>>  Log:
>>>>  Increment the version namespace for 8.0-current.  New symbols and
>>>>  symbols whose ABI has changed should be added to FBSD_1.1.
>>>
>>> Why do new symbols have to be added to 1.1 instead of 1.0?
>>
>> There is no technical reason they cannot be, but this is what we
>> decided some time ago.  That each time head is branched, a new
>> version is created and new and ABI-changed symbols get added to
>> it.  It makes it easy to track when (initially in which major
>> FreeBSD version) symbols get added.  I should have also noted
>> that this was discussed with kan and das (not des) prior to
>> commit.  kan's other comment was that this would also make it
>> easier to write tools that can tell if an application built on
>> release X can run on release Y (where Y < X).
>>
>> We can still MFC new symbols back to prior releases, we just
>> have to add them to the same namespace from which they came.
>
> Daniel, is there anything preventing us from matching version
> numbers with release numbers?  This would make things a bit
> more intuative.

This was already discussed before.  I do not think it is a good
idea - it is easy to create a lookup table matching version
numbers to release numbers if that is needed for ABI checking
tools, and simple comments in the version defs file makes it
apparent to anyone looking at it.  I don't think we want to
tie release numbers to version numbers, and when you backport
changes, it makes it confusing because you now have FBSD_8
symbols in releng_7.  Other packagers may also not be using
the same release numbering scheme that the project uses.
Sun for instance does not name their versions after releases,
they use SUNW1.0, SUNW_1.1, etc.  Also, there may be multiple
ABI changes in HEAD that warrant bumping the version number
more than once (akin to bumping library versions, but this
hasn't yet happened in the past).  There would be no
corresponding release to match, but you would have to bump
the version number regardless.

The version numbering is not something that is easily visible
to the user.  It is simpler and more flexible to avoid tying
version numbers to release numbers, and to write ABI checking
tools (easily done with scripts) to do what we need.

-- 
DE