On Tue, Jul 09, 2013 at 04:14:22PM -0700, Adam Williamson wrote: +1 For most libraries I think that an api-compatible version bump wouldn't need to even go through the Planning process. But some things, like glibc, are depended upon by so many other things that they need to be system-wide changes so that people can be on the lookout for unexpected problems that it might cause. -Toshio

Oops as noted by jreznik, this thread took a brief detour onto the docs list by mistake. On Wed, Jul 10, 2013 at 11:47:30AM -0400, Robyn Bergeron wrote: For most libraries, that's probably a good rule of thumb. I can think of some caveats to the rule of thumb though: * Libraries can also refer to scripting languages' modules which might not need a mass rebuild. * Changes may not change the API/ABI or SONAME of elf libraries so they don't need a mass rebuild but they still might require testing or coordination across many packages. ** The setuptools update: https://fedoraproject.org/wiki/Changes/Python_setuptools_0.7 Is an example of both of those caveats -- it's a scripting language and the changes are not supposed to change API. But the update is an upstream rewrite of a large amount of the codebase and the package is used by a large number of other packages in Fedora. So testing and communication of the change is the reason for the System-wide-change designation. glibc, I think, is an extreme example of the second caveat. glibc has an effect on close to everything in the distirbution. Upstream rebases should probably always be treated as system-wide changes so that other packagers can watch out for bugs or changes in behaviour that might be due to glibc rather than their own package's code. -Toshio