symbols.map stanza names

[Christopher James Halse Rogers]

On Sat, Aug 29, 2015 at 2:27 AM, Alexandros Frantzis 
<alexandros.frantzis at canonical.com> wrote:
> On Fri, Aug 28, 2015 at 04:46:24PM +0100, 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.
> 
> +1 to including the release version in the stanza name.
> 
> As for the naming scheme I would propose the following variation:
> 
> MIRPLATFORM_9_symbols_from_0.15
> MIRPLATFORM_9_symbols_from_0.16
> ...
> 
> and when we bump ABI and consolidate, let's say in 0.17:
> 
> MIRPLATFORM_10_symbols_from_0.17

This seems sensible; I'd probably paint the bikeshed MIRPLATFORM_9+0.16.

We're not constrained by matching SOVER here, so we could even go crazy 
and call them MIRPLATFORM_0.16 etc. I don't know if encoding the SOVER 
there is valuable.

If we do this it'd be nice if the current version to target was in at 
least one of the IRC topics :)