cvs commit: src/lib/libc Versions.def

[Alexander Leidinger]

Quoting Daniel Eischen <deischen at freebsd.org> (from Tue, 18 Dec 2007  
07:32:19 -0500 (EST)):

> 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.

I asked already something like the following, but haven't seen an  
answer, what about:
  - RELENG_7_0 with FBSD_1.0
  - RELENG_7_1 with FBSD_1_1 in case of an addition
                             to the ABI
  - RELENG_8_0 with FBSD_1.0 and
                    FBSD_2.x and
                    FBSD_1.1 in case of an addition
                             to the ABI in RELENG_7

Bye,
Alexander.

-- 
The warning message we sent the Russians was a
calculated ambiguity that would be clearly understood.
		-- Alexander Haig

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137