$/!\$ This page is a strawman proposal for the release management of GTK+; it is part of the discussion that led to the versioning and long term stability promise that is currently in effect. We're preserving this page for historical reasons. $/!\$

GTK+ life cycle considerations

At the GTK+ hackfest in Toronto, 2016, we discussed our approach to life cycle handling for stable and unstable release branches of GTK+. This page is meant to be the staging ground for a detailed writeup of the proposal, to serve as a basis for discussion at GUADEC 2016 in Karlsruhe.

Update: the GTK+ team has reached a consensus, see the announcement on the GTK+ development blog:

Versioning and long term stability promise in GTK+

Background

By the end of the GTK+ 2.x cycle, the toolkit was starting to feel outdated. A more rapid pace of development was required in order to modernize. This was achieved during the 3.x series, with major internal changes producing a massive improvement in feature set and usability for developers.

However, this modernization effort came at a cost: changes required API/ABI breaks between releases. While an effort to minimize the impact on applications was made, applications were frequently required to update for each successive 3.x release. To add to these problems, there was a lack of clarity: it was difficult for application developers to know what they could expect in terms of stability between releases.

The following proposal is an attempt to resolve these difficulties, by:

Allowing a rapid pace of development, which is required in order to have a modern toolkit.
Provide releases that are viable for a long period of time, so that applications don't have to update every 6 months because of toolkit changes, if they don't want to.
Clearly communicate our policies around API/ABI stability, so that applications can be confident in what they can expect from GTK+.

The Proposal

This proposal is in development and is open to change, particularly in response to feedback (see below). It is just a proposal at this stage.

Releases will be made every six months, in tandem with the GNOME release schedule. Every new release will have a new soname.
- New feature work will be introduced with each release, and may result in some breakage for applications. Instability may be greater than in previous 3.x versions, but will not be as great as the 2.x → 3.x transition.
- If new features conflict with existing ones, API might be removed, rather than being deprecated.
- Despite an anticipated increase in instability between releases, there will be an effort to limit breakage as much as possible. The goal is to keep changes manageable for applications, so that applications (such as the GNOME apps) can keep track if they want to.
- Dependent libraries will be required to bump soname every six months.
One in four releases will be treated as being a "long-term updates" release.
- Long-term update releases will receive minor updates for two years. These will include bug fixes and other small updates, but will not include major new features or changes that require applications to update. This will be similar to the GTK+ 2.24 branch.
- Updates to long-term update releases will match our current stability promises for stable branches.
- Long-term update releases will be parallel installable with normal ones. Applications will be able to choose whether to target a long-term updates GTK+ version or a regular one.
- Deprecated symbols will be removed with each long-term update release, as has been existing policy for .0 releases.
Non-long-term update releases will receive minimal minor updates, as is standard for GTK+ releases.
This proposal isn't planned to come into effect until at least 2017.

Versioning Schema

The exact approach to versioning releases has yet to be decided. There are several possibilities (the version numbers in these diagrams are illustrative, since an exact time frame has not been agreed on):

Version 1

The first long-term update release is named version 3.26. Long-term update releases come at the end of each release series, and have a .6 version number.

Version 2

The first long-term update release is named version 4.0. Long-term update releases begin each release series, and have a .0 version number.

FAQ

/FAQ

Blog Posts

See some blog posts for background:

Comments and Feedback

The above is a proposal only, and will only be adopted after discussion with community members, partners and stakeholders has taken place. We want to hear your views, so please get in touch using gtk-devel-list@gnome.org or find us on IRC, in #gtk+ on GimpNet.

Thread on gtk-devel-list