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@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
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
