From: Martin H. <mar...@si...> - 2012-08-23 01:56:21
|
Dear Rene, > On Wed, Aug 22, 2012 at 04:18:07PM +0700, Martin Hosken wrote: > > The next version of the graphite engine (1.2.0) will have some new API functions added and some deprecated. As a result we need to increase the interface number and we can also increase the age (since we aren't changing or deleting any functions). > > Forgive me, but what ends up as/in the SONAME as of those? > > > Thus we are going from 2.0.0 to 3.0.1 (this is separate from the release numbering scheme). > > Ah, so this will be -3.0.1 as SONAME then. Bad. > > > I.e. we will be binary backwardly compatible with the existing API. > > Then you don't need to change it :) OK. Here's where I share my confusion (hence raising the issue). My understanding (which is probably wrong) is that if you add functions to your API and then an application uses those functions (which we want to encourage and deprecate some other ones for future removal), then how can that application be sure that it has the right version of library that has the new functions? I was assuming you had to bump the interface number in that case. Or is it sufficient to bump the bug fix number and we could go to 2.1.0? It would be much easier to stay at 2.0.0 if we can. So I am all in favour of finding an interpretation of the rules that lets us not change things. Your expertise and experience here would be valued, Rene. > If you ever *remove* the now-deprecated functions that's an other matter > as you then become binary-incompatible, yes, but now... Yes. This will have to happen one day. But for the longer we can delay that, the better. Thanks, Yours, Martin |