On Sun, 8 Nov 2015 07:49:05 +0100 Andreas Metzler <ametz...@bebt.de> said:
> On 2015-11-07 Carsten Haitzler <ras...@rasterman.com> wrote: > > On Sat, 7 Nov 2015 08:18:55 +0100 Andreas Metzler <ametz...@bebt.de> said: > [...] > >> Jumping in, let me outline the question a little bit more extensively: > > >> Let's assume I found that there is ABI breakage when upgrading > >> libfoo from efl 1.8 to libfoo from efl 1.15 while both releases of > >> libfoo shared the same soname. i.e. a binary built against > >> libfoo-efl1.8 will stop working correctly when libfoo is upgraded to > >> libfoo-efl1.15. If I reported a bug about this issue would you > >> consider it to be release-critical and would you resolve it by either > >> fixing the ABI breakage or bumping the soname? > > > how does THAT mean there is an ABI break? it could simply be that > > there was reliance on undefined behavior that has now changed, or > > the app was LUCKY to not trigger a bug before and now it does. just > > because something used to work and now doesn't does NOT mean there > > is an ABI break. you don't know until you dig in and find out. > > Hello, > > yes, you are right. I was trying to ask about a "real" ABI > break, i.e. public interfaces breaking and requiring a rebuild (or > even source changes) in reverse dependencies. > > >> (Obviously this implies that I generally would not usually find such > >> issues, since making sure that ABI breakage is avoided would be part > >> of the release process.) > > > we actually run ABI reports every release (these check structures, > > actual function call signatures, symbols etc.). we don't break our > > ABI according to this > > Ok, that is great, thanks. > > > (unless of course you rely on api documented > > to be unstable - eg like eo. that we document to be experimental > > and we do break it). > > Which means that we should not ship the eo API in Debian. you have no choice. efl depends on it. eg elementary cannot be compiled without eo api's exposed from efl. WE keep elm in sync with efl, so it will work. just to begin. secondly you cannot "access" eo api unless you define a special #define in your app before including efl headers. without it the eo api is ifdef'ed out (hidden). so anyone using it is making a very explicit choice to use it. you need to read documentation to figure out how to turn it on, and this will tell you that it is unstable. :) > However afaict e.g. elementary only provides an eo API since 1.13 and is > required by E. it's earlier than that. :) see above. > cu Andreas > > -- > `What a good friend you are to him, Dr. Maturin. His other friends are > so grateful to you.' > `I sew his ears on from time to time, sure' > > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
