2013/11/19 Bob Beck <b...@obtuse.com>: > I'm inclined to agree with marc here - we bump minors on api additions > - and yes, it was stubbed there before so it's not really an > "addition" but it was stubbed to fail and had to be worked around - > bump the minor - not like it's a big deal. > > On Tue, Nov 19, 2013 at 12:02 AM, Marc Espie <es...@nerim.net> wrote: >> On Tue, Nov 19, 2013 at 12:11:17AM -0500, Ted Unangst wrote: >>> On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote: >>> >>> >> btw, no library version change because the function stubs already >>> >> existed. >>> > >>> > Hmm, since this is actually offering new functionality (by sem_open() >>> > and friends no longer always failing), I think it a minor bump would >>> > be appropriate. Consider that a program with an autoconf test of >>> > sem_open() will now return a different answer, just as if sem_open() >>> > was completely new. no? >>> >>> I hear you, but disagree. We fix program disabling bugs in libraries >>> frequently without bumping. I have always thought of library >>> versioning being more about "program integrity", as in all the pieces >>> you expect to find are all there, but it doesn't say anything about >>> the inner workings of the pieces. >> >> As theo says, there are other library bumps later, but you're wrong. >> >> Use-case: new packages, slightly older snapshots. New packages actually >> make use of sem_open, because of said added functionality. Without a bump, >> pkg_add will allow to add them, and they won't work, because the >> functionality >> wasn't there... >> >> It is added functionality. It's not a minor bugfix.
I know at least one software piece for which changing the behaviour of sem_open() changes the behaviour of this software itself - KSharedDataCache from kdelibs (the one I've talked on EuroBSDCon, btw). It tries at run-time to call sem_open(foo, 1), and if it fails, goes other way; and particular execution path affects the on-disk structures, too! In case of KSharedDataCache it isn't really an issue (cache could be rebuilt in the worst case), but there could be others in ports with much worse effects. I mean, behavior change in this case should be probably accompanied with major lib version bump, so we could at least differentiate packages. -- WBR, Vadim Zhukov
