Mark M. Hoffman wrote: > Hi Hans: > <discussion about 3.0 versus increments snipped> > > I don't agree. I think the sum of changes we are planning does warrant the > move to 3.0. It will be easier than the alternative, e.g.: > > 2.10.4 - drop support for 2.4.x proc file access > 2.10.5 - new API function > 2.10.6 - include command in config file > Okay, first of all this is me with my lmsensors-contributers hat firmly off and my packager maintaining over a 100 packages in Fedora hat firmly on: Lets try to split 2 things here, doing a 3.0 release to indicate some kinda milestone and breaking the ABI. I've got nothing against putting some big changes (esp dropping 2.4 support) in a 3.0 release. However unless it really is necessary I'm against breaking the ABI. Adding a function does not break any old applications and thus is not a problem, most distributions work with repositories of packages, whereby new packages for a repo get build against other packages already in the same repo. Thus before any new package in such a repo can use the new API functions, libsensors must be updated first. Then applications may start using the new function after being (re)build against the repo with the new libsensors in it. Normal users use some update tool which will automaticly install all new packages including the new libsensors + any apps needing the new version. Now one can do so called piecemeal upgrades manually but that is asking for trouble and usually voids your support if any. One of the great successes of gtk2 actually is that every new release is ABI compatible with the old, so old apps stay working. Also keep in mind that besides package-manager installed apps a user may also have manually installed apps. When the package manager then updates a library to a new not ABI compatible (and thus hopefully a different soname) version, these manually installed apps will break. In short soname changes / ABI breakage cause both user and packager pain and inconvenience. Thus if it isn't really necessary / there is little gain, as with the by const reference versus by value change you propose, then you should not break the ABI and thus keep the soname. Regards, Hans
