symbols.map stanza names

[Daniel van Vugt]

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