On Thu, Sep 10, 2015 at 1:28 AM, Alan Griffiths
wrote:
After today's standup Stephen said that Chris will update the
doc/dso_versioning_guide.md to incorporate the ideas from this thread.
There's a proposal up at
https://code.launchpad.net/~raof/mir/new-dso-versioning-policy/+merge/273186
no
After today's standup Stephen said that Chris will update the
doc/dso_versioning_guide.md to incorporate the ideas from this thread.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
On Wed, Sep 2, 2015 at 1:26 PM, Daniel van Vugt
wrote:
Hypothetically the "9" could now go away. Internally that's fine:
MIR_PLATFORM_0.16
Right. I even suggested this upthread.
But externally if we started naming the files as such then it might
get confusing:
libmirplatform.so.0.17
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
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 name
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_fu
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
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 loo
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 benef
On Sat, Aug 29, 2015 at 2:27 AM, Alexandros Frantzis
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:
MIRPLA
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 {
> ...
> } MIRPLAT
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 MIR
12 matches
Mail list logo
