Re: Versioning and long term stability promise in GTK+
- Date: Mon, 30 Jan 2017 19:46:38 +0100
- From: Sébastien Wilmet <swilmet@xxxxxxxxx>
- Subject: Re: Versioning and long term stability promise in GTK+
On Mon, Jan 30, 2017 at 11:17:55AM +0000, Emmanuele Bassi wrote:
> On 29 January 2017 at 10:00, Sébastien Wilmet <swilmet@xxxxxxxxx> 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.
gtk-devel-list mailing list