On Sat, Aug 29, 2015 at 2:27 AM, Alexandros Frantzis
<alexandros.frant...@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 :)
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
