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 gnome org> wrote:
On Sat, Sep 03, 2016 at 02:09:04PM +0100, Emmanuele Bassi wrote:

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]