Re: Versioning and long term stability promise in GTK+

Hi;
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.
> 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.
> 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.
Ciao,
Emmanuele.
--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-devel-list