> 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.
The current window you are arguying about is maybe from Oct 24, definately Oct 22. For many pkgs, a few other intermediate bumps mattered. A libc crank is coming uhm, rather shortly. Melodrama.
