On Tue, 28 Aug 2007, Yar Tikhiy wrote:
> On Mon, Aug 27, 2007 at 05:38:08PM -0400, Daniel Eischen wrote:
>>
>> An example (for the sake of this example, let's assume that all
>> non-fts symbols are in FBSD_1.0, and fts_* are in FBSD_1.1):
>>
>> FILE changes in -current, the new symbol map would add the FILE-related
>> APIs.
>>
>> FBSD_1.1 {
>> fts_open; <- existing
>> fts_read; <- existing
>> ...
>> fts_close; <- existing
>> fopen; <- new
>> fread; <- new
>> ...
>> fclose; <- new
>> } FBSD_1.0;
>>
>> A week later, pthread_mutex_t changes in -current. You add the
>> pthread_mutex_t-related APIs:
>>
>> FBSD_1.1 {
>> fts_open; <- existing
>> fts_read; <- existing
>> ...
>> fts_close; <- existing
>> fopen; <- existing
>> fread; <- existing
>> ...
>> fclose; <- existing
>> pthread_mutex_init; <- new
>> pthread_mutex_lock; <- new
>> ...
>> pthread_mutex_destroy; <- new
>> } FBSD_1.0;
>>
>> You are not forced to rebuild any ports by adding symbols to FBSD_1.1.
>> Everything that was built before the pthread_mutex_t change will work
>> after the change. You can keep adding to FBSD_1.1 and only need to
>> go to FBSD_1.2 if one of the APIs in FBSD_1.1 undergoes yet another
>> ABI change.
>
> I guess everything will work after changing pthread_mutex_t if either
> nothing calls pthread_mutex functions or compatibility shims for them
> are provided under FBSD_1.0. Is it correct?
Yes, though I was assuming that compat shims are added whenever
you change the ABI. For this example, we know that there are
a lot of applications that use pthread_mutex-related APIs, so
the appropriate compat shims would definitely be needed.
>> If the fts_* stuff goes in now as FBSD_1.0, I guess you don't
>> need to go to FBSD_1.1. You can stay at FBSD_1.0 until you
>> have the next ABI change. If fts_* goes in now as FBSD_1.1 (and
>> assuming all the other symbols stay at FBSD_1.0), then you can
>> just keep adding to FBSD_1.1 after the branch/release. If all
>> the symbols along with fts get pushed to FBSD_1.1, then you
>> have to go to FBSD_1.2 at the next ABI change.
>
> Just to make things clear: if FBSD_1.0, FBSD_1.1, and FBSD_1.2 are
> already populated with some symbols and a symbol from FBSD_1.0
> undergoes an incompatible change, which version it should be promoted
> to, FBSD_1.1 or FBSD_1.2? AFAIK, technically either is possible.
Correct, you can add the new APIs to either FBSD_1.1 or FBSD_1.2,
and I do raise this question (as a TBD) in:
http://people.freebsd.org/~deischen/symver/freebsd_versioning.txt
I would think that we would always use the latest version when
adding new ABI changes to -current. In release branches, MFCs
have to go the the same version from which they came in -current
(to maintain forward compatibility).
--
DE