symbols.map stanza names

[Daniel van Vugt]

Although you can easily avoid being wordy and have the best of both worlds:

   MIRPLATFORM_9.0.16
   MIRPLATFORM_9.0.17


On 31/08/15 09:57, Daniel van Vugt wrote:
> I've considered using your suggested approach but also been using an
> arguably cleaner solution for around the past year[*]. If you look in
> src/client/symbols.map you will find:
>
>    MIR_CLIENT_9.1 {  # New functions in Mir 0.15
>
> It's no less foolproof than what you suggest, but has the added benefit
> of not over-growing symbol names embedded in the binaries.
>
> Given that symbol name length is a major cause of binary bloat in C++
> already, that's something to consider...
>
>
> [*] Past year but you won't find many traces of it because we keep
> deleting the entries with comments when they get subsumed by major ABI
> bumps.
>
>
> On 28/08/15 23:46, Alan Griffiths wrote:
>> The current approach to naming stanzas in the symbol maps leads to a
>> potential for mistakes. For example, src/platform/symbols.map has the
>> following stanzas:
>>
>> MIRPLATFORM_9 {
>> ...
>> }
>>
>> MIRPLATFORM_9.1 {
>> ...
>> } MIRPLATFORM_9;
>>
>> It is far from obvious when adding a symbol whether it should be added
>> to MIRPLATFORM_9.1 or to a new MIRPLATFORM_9.2. As it happens
>> MIRPLATFORM_9.1 was created after 0.15 was branched so that is the
>> "right one". But it isn't obvious: If MIRPLATFORM_9.1 had shipped in
>> 0.15 then MIRPLATFORM_9.2 would be right.
>>
>> I don't know of any reason why we name stanzas this way except
>> "tradition".
>>
>> What does the team think of using this instead?
>>
>> MIRPLATFORM_9_new_symbols_from_0.16 {
>> ...
>> } MIRPLATFORM_9;
>>
>> And after we branch release 0.16 it is clearer we should add:
>>
>> MIRPLATFORM_9_new_symbols_from_0.17 {
>> ...
>> } MIRPLATFORM_9_new_symbols_from_0.16;
>>
>> When the ABI breaks we consolidate as before.
>>
>