symbols.map stanza names

[Daniel van Vugt]

Hypothetically the "9" could now go away. Internally that's fine:
    MIR_PLATFORM_0.16

But externally if we started naming the files as such then it might get 
confusing:
    libmirplatform.so.0.17.0
    libmirplatform.so.0.16 -> libmirplatform.so.0.17.0
    libmirplatform.so -> libmirplatform.so.0.16
Means the Mir release is 0.17.0 but the ABI level (soname) is still 
0.16. Actually that's not too confusing. It might be preferable even.


On 02/09/15 10:45, Daniel van Vugt wrote:
> Yes MIR_PLATFORM_9v0.16.0 would work. Although I had hoped that we don't
> get into the habit of adding to the ABI in point releases, so it could
> be just: MIR_PLATFORM_9v0.16
>
> I'm also open to replacing 'v' with something non-alphanumeric.
>
> The same scheme could be applied to the library file names too:
>     https://bugs.launchpad.net/mir/+bug/1490428
>
> Although the 'v' doesn't feel like the cleanest syntax. In an ideal
> world your ABI number _is_ you major version number, so it just works
> out as a version string.
>
>
> On 02/09/15 00:39, Alan Griffiths wrote:
>> On 31/08/15 04:25, Daniel van Vugt wrote:
>>> I think there's another reason to not use the plural "symbols" in the
>>> stanza name as has been suggested. Because we're actually talking
>>> about the end result of how individual symbols are named:
>>>
>>> some_new_function@@MIR_PLATFORM_9.2
>>> some_new_function at MIR_PLATFORM_9.1 # Slightly less new
>>>
>>> So ideally each one should not be named "*symbols*". Even using the
>>> word "symbol" is redundant. We're just adding version suffixes really,
>>> so keep that in mind.
>>
>> OK, how about:
>>
>> MIR_PLATFORM_9v0.16.0
>>
>>