On Mon, Jan 30, 2017 at 11:17:55AM +0000, Emmanuele Bassi wrote: > On 29 January 2017 at 10:00, Sébastien Wilmet <swil...@gnome.org> wrote: > > On Sat, Sep 03, 2016 at 02:09:04PM +0100, Emmanuele Bassi wrote: > >> https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/ > > > > In the above announcement, you've written: > > I didn't write it, but since I reviewed it, let's assume I did.
(By "you" I was using the plural form, the GTK+ team, not you specifically, I know it was written/reviewed by several people ;) > > More details about these plans, including specifics for library > > developers and distribution packagers, will follow in subsequent > > blog posts. > > > > Those subsequent blog posts have not yet been posted. If you've written > > that, it probably means that you wanted to explain more things. > > Not really. That paragraph means: "other libraries will explain their > own plans once they decide them, and if the maintainers of those > libraries wish to share them through the GTK development blog, we will > publish them here". Since no other library has published their > intentions, or contacted the GTK team about those, we're still > waiting. I know that you sent your plans for GtkSourceView to > desktop-devel-list and to your blog, for instance. Mmh I might have read the sentence wrong. "for library developers", I understand it as "for developers like me who develop GtkSourceView", not "for application developers who use higher-level libraries". > > For a higher-level library based on GTK+, a GTK+ API break can force an > > API break in the higher-level library. So during the GTK+ 3.9x versions, > > the higher-level library cannot really guarantee API stability. > > They can guarantee API stability in the same way GTK+ does — with API > that changes throughout the .9x minor releases, but not between micro > releases, and bump the soname every time the ABI changes. > > > Normally, each time there is an API break, the Libtool version must be > > bumped (increment CURRENT, set REVISION to 0 and set AGE to 0). Is that > > all there is to know about handling API instability in higher-level > > libraries? Maybe you have other things in mind. > > That's the idea behind the soname bump that we are using in GTK+ x.9y cycles" > > | Each of these minor versions will bump the soname of the shared library, > | to ensure that automated tools can pick up the eventual changes and notify > | distributors and maintainers. > > We're going to reset the soname every time we do a new .9x minor > release; this is enough to cause any application and library that > depends on GTK+ to be rebuilt, and allows distributions to change the > package name. Maybe another thing to explain to higher-level library developers, even if it looks obvious: using the same minor versions: 89 (unstable), 90 (semi-stable), 91, etc. So that there is some kind of consistency between libraries, even if the major version is not the same. -- Sébastien _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
