On Fri 2018-02-23 12:57:09 +0100, Tim Rühsen wrote:
> Well, adding or removing a flag *is* a change of the interface. Not
> clear here if 'interface' means 'function'. From a logical point of
> understanding it could be anything changing the behavior of the library
> *or* the application. That means it could be flags, enum values,
> functions, function params, defines, ...

agreed, the semantics are fuzzy here.

> An *automated* stable (packaging and runtime) behavior could only be
> achieved if SONAME gets bumped in any of the above cases. If we revert
> the bump, there will be chances to get an unstable behavior (as you
> stated as well). Even if only one person is affected and even if that is
> unlikely - why open up a hole ?

well, bumping the SONAME also means that it's a "library transition",
which means that everything which builds against libpsl.  Gratuitous
library transitions make the buildd maintainers grumpy :/

I note that if all previous versions had returned something like
ENOTIMPL if they detected a flag that they didn't know about, an SONAME
bump *definitely* wouldn't be required (at the expense of the library
user needing to be able to handle an additional error case at runtime).

Anyway, i'm inclined to revert the SONAME bump for this one, and move it
back to 8:0:3 -- but if you add code to provide ENOTIMPL-ish semantics,
then i'd be inclined to consider that worth doing the SONAME bump for,
since it means we'll have a clear way to add new flags in the future.

what do you think?


You received this message because you are subscribed to the Google Groups 
"libpsl-bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to libpsl-bugs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to