New versioning scheme in gtk+. And in gtkmm?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

New versioning scheme in gtk+. And in gtkmm?

Kjell Ahlstedt

Gtk+ has announced a new versioning scheme:
https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk

Now the gtk+ developers have created a gtk-3-22 branch and started removing deprecated API in the master branch. I guess we have to do the same in gtkmm whether we like it or not, if we want gtkmm to be compatible with gtk+'s master branch. Is there a reasonable alternative?

Kjell


_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: New versioning scheme in gtk+. And in gtkmm?

Murray Cumming-5
On Tue, 2016-10-25 at 16:22 +0200, Kjell Ahlstedt wrote:
> Gtk+ has announced a new versioning scheme:
> https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-pr
> omise-in-gtk
> Now the gtk+ developers have created a gtk-3-22 branch and started
> removing deprecated API in the master branch. I guess we have to do
> the same in gtkmm whether we like it or not, if we want gtkmm to be
> compatible with gtk+'s master branch. Is there a reasonable
> alternative?
> Kjell

Agreed. Anything else would be even more confusing.

--
Murray Cumming
[hidden email]
www.murrayc.com

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: New versioning scheme in gtk+. And in gtkmm?

Murray Cumming-5
Because we are creating a new parallel-installable gtkmm ABI (gtkmm-
4.0), for use with GTK+ 4.0, this is a fairly good time to do the same
with glibmm, though glib will not have a new ABI at this time.

That let's us remove some deprecated API and let's us depend on the
newer, simpler (because it's C++14) libsigc++-3.0. That means that
gtkmm-4.0 would require C++14, but I think that should be fine for
anyone who's likely to want to use it.

The last stable version of glibmm (the glibmm-2.4 ABI) was glibmm 2.50,
so we would have to call our new glibmm ABI glibmm-2.52. That's not
pretty, but I don't see a better alternative. We can't call it glibmm-
3.0 because that would cause problems when there is a glib-3.0 one day.

Any objections?

--
Murray Cumming
[hidden email]
www.murrayc.com

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: New versioning scheme in gtk+. And in gtkmm?

Murray Cumming-5
On Thu, 2016-11-10 at 12:15 +0100, Murray Cumming wrote:

> Because we are creating a new parallel-installable gtkmm ABI (gtkmm-
> 4.0), for use with GTK+ 4.0, this is a fairly good time to do the
> same
> with glibmm, though glib will not have a new ABI at this time.
>
> That let's us remove some deprecated API and let's us depend on the
> newer, simpler (because it's C++14) libsigc++-3.0. That means that
> gtkmm-4.0 would require C++14, but I think that should be fine for
> anyone who's likely to want to use it.
>
> The last stable version of glibmm (the glibmm-2.4 ABI) was glibmm
> 2.50,
> so we would have to call our new glibmm ABI glibmm-2.52. That's not
> pretty, but I don't see a better alternative. We can't call it
> glibmm-
> 3.0 because that would cause problems when there is a glib-3.0 one
> day.

I have pushed the changes to the git master branches.

So we now have:
* glibmm-2.52 instead of glibmm-2.4
* cairomm-1.14 instead of cairomm-1.0
* pangomm-2.42 instead of pangomm-1.4
* atkmm-2.26 instead of atkmm-1.6
* gtkmm-3.0 instead of gtkmm-2.4

That is a bit of a mess, so I welcome alternative suggestions, though I
 guess this is how it must be.


--
Murray Cumming
[hidden email]
www.murrayc.com

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: New versioning scheme in gtk+. And in gtkmm?

Murray Cumming-5
On Mon, 2016-11-14 at 10:51 +0100, Murray Cumming wrote:
> * glibmm-2.52 instead of glibmm-2.4
> * cairomm-1.14 instead of cairomm-1.0
> * pangomm-2.42 instead of pangomm-1.4
> * atkmm-2.26 instead of atkmm-1.6
> * gtkmm-3.0 instead of gtkmm-2.4

I mean gtkmm-4.0 instead of gtkmm-3.0.

--
Murray Cumming
[hidden email]
www.murrayc.com

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: New versioning scheme in gtk+. And in gtkmm?

Murray Cumming-5
On Mon, 2016-11-14 at 11:08 +0100, Murray Cumming wrote:
> > * glibmm-2.52 instead of glibmm-2.4
> > * cairomm-1.14 instead of cairomm-1.0

This is now cairomm-1.16 instead.

> > * pangomm-2.42 instead of pangomm-1.4
> > * atkmm-2.26 instead of atkmm-1.6
> > * gtkmm-3.0 instead of gtkmm-2.4
>
> I mean gtkmm-4.0 instead of gtkmm-3.0.


--
Murray Cumming
[hidden email]
www.murrayc.com

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: New versioning scheme in gtk+. And in gtkmm?

Murray Cumming-5
On Wed, 2016-11-16 at 13:56 +0100, Murray Cumming wrote:

> > > * glibmm-2.52 instead of glibmm-2.4
> > > * cairomm-1.14 instead of cairomm-1.0
>
> This is now cairomm-1.16 instead.
>
> > > * pangomm-2.42 instead of pangomm-1.4
> > > * atkmm-2.26 instead of atkmm-1.6
> > > * gtkmm-3.0 instead of gtkmm-2.4
> >
> > I mean gtkmm-4.0 instead of gtkmm-3.0.

We might choose to wait a bit longer, letting us do another stable
glibmm and gtkmm release, maybe then changing the glibmm-2.52 ABI name
to glibmm-2.54, for instance.

I don't know when the GTK+ developers plan to call their GTK+-4.0 API
stable, but it's obviously not going to be ready for the next GNOME
release in March 2017.

There's no sign of a gtk-3-24 branch yet for GTK+, but we might still
release 3.24.* versions of gtkmm-3.0.

Let's see how things develop over the next few weeks.

--
Murray Cumming
[hidden email]
www.murrayc.com

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: New versioning scheme in gtk+. And in gtkmm?

Murray Cumming-5
On Sat, 2017-01-14 at 15:25 +0100, Murray Cumming wrote:
> We might choose to wait a bit longer, letting us do another stable
> glibmm and gtkmm release, maybe then changing the glibmm-2.52 ABI
> name
> to glibmm-2.54, for instance.

glibmm 2.52.0 has been released, but not GTK+ 4.0.0, so now is probably
the time to do this.

> I don't know when the GTK+ developers plan to call their GTK+-4.0 API
> stable, but it's obviously not going to be ready for the next GNOME
> release in March 2017.
>
> There's no sign of a gtk-3-24 branch yet for GTK+, but we might still
> release 3.24.* versions of gtkmm-3.0.
>
> Let's see how things develop over the next few weeks.

There's still no gtk+ 3.23/24, but we could still consider doing gtkmm
3.24/25. For now, I guess there is not a great demand for it.

--
Murray Cumming
[hidden email]
www.murrayc.com

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: New versioning scheme in gtk+. And in gtkmm?

Chris Vine
On Tue, 21 Mar 2017 17:22:58 +0100
Murray Cumming <[hidden email]> wrote:

> On Sat, 2017-01-14 at 15:25 +0100, Murray Cumming wrote:
> > We might choose to wait a bit longer, letting us do another stable
> > glibmm and gtkmm release, maybe then changing the glibmm-2.52 ABI
> > name
> > to glibmm-2.54, for instance.  
>
> glibmm 2.52.0 has been released, but not GTK+ 4.0.0, so now is
> probably the time to do this.
>
> > I don't know when the GTK+ developers plan to call their GTK+-4.0
> > API stable, but it's obviously not going to be ready for the next
> > GNOME release in March 2017.
> >
> > There's no sign of a gtk-3-24 branch yet for GTK+, but we might
> > still release 3.24.* versions of gtkmm-3.0.
> >
> > Let's see how things develop over the next few weeks.  
>
> There's still no gtk+ 3.23/24, but we could still consider doing gtkmm
> 3.24/25. For now, I guess there is not a great demand for it.

It is possible I am wrong (the original naming proposals were changed
and I may have missed something) but I do not think there is ever
intended to be a 3.23/24.  As I understand it, 3.22 has become like
2.24: it will be maintained for some time - as a minimum 2 years - but
no new additions or changes of any kind (including CSS/theming and
gobject-introspection changes) will be made in the future.

I think it was intended to be 2 years before gtk+-4 comes out. In the
meantime gtk+-3.89/3.9* (the development series for gtk+-4) is supposed
to be in use by most gnome components during that period even though
API/ABI might change in it.  In fact nothing in gnome-3.23/3.24 uses it
(apart from gtkmm-3.89).  I can't say I am surprised.  No one
particularly likes to rewrite existing code and many gnome components
use functions deprecated in later versions of gtk+3 and removed from
gtk+-3.89.
_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: New versioning scheme in gtk+. And in gtkmm?

Daniel Boles
On 22 March 2017 at 10:04, Chris Vine <[hidden email]> wrote:
It is possible I am wrong (the original naming proposals were changed
and I may have missed something) but I do not think there is ever
intended to be a 3.23/24.  As I understand it, 3.22 has become like
2.24: it will be maintained for some time - as a minimum 2 years - but
no new additions or changes of any kind (including CSS/theming and
gobject-introspection changes) will be made in the future.

Yeah, but the question is different. It's whether gtkmm can have a 3.24 that will be able to add new API,
e.g. for missing things or for new things that are shoehorned into GTK+ 3.22 when they probably shouldn't be.
Alternatively we could just start shoehorning too.


_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: New versioning scheme in gtk+. And in gtkmm?

Murray Cumming-5
In reply to this post by Chris Vine
On Wed, 2017-03-22 at 10:04 +0000, Chris Vine wrote:
> I think it was intended to be 2 years before gtk+-4

That sounds about right. Do you happen to have a link to where someone
states that officially?

--
Murray Cumming
[hidden email]
www.murrayc.com

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: New versioning scheme in gtk+. And in gtkmm?

Chris Vine
On Thu, 23 Mar 2017 11:51:00 +0100
Murray Cumming <[hidden email]> wrote:
> On Wed, 2017-03-22 at 10:04 +0000, Chris Vine wrote:
> > I think it was intended to be 2 years before gtk+-4  
>
> That sounds about right. Do you happen to have a link to where someone
> states that officially?
 
This seems the most current one, as far as I can tell:

https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/

One point is that version 3.90 has still not been reached.  gtk+ still
seems stuck on gtk+-3.89, notwithstanding that gnome-3.24 has now come
out.

Chris
_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Fwd: New versioning scheme in gtk+. And in gtkmm?

Daniel Boles

On 23 March 2017 at 15:09, Chris Vine <[hidden email]> wrote:
One point is that version 3.90 has still not been reached.  gtk+ still
seems stuck on gtk+-3.89, notwithstanding that gnome-3.24 has now come
out.

I don't think there is any relation between GNOME releases and the development of GTK+ 4. As far as I know, version 3.89 is really v4 alpha and will remain at that number until it's beta-worthy, at which point it will become 3.90 and so on.




_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: New versioning scheme in gtk+. And in gtkmm?

Chris Vine
On Thu, 23 Mar 2017 15:19:51 +0000
Daniel Boles <[hidden email]> wrote:

> On 23 March 2017 at 15:09, Chris Vine <[hidden email]>
> wrote:
>
> > One point is that version 3.90 has still not been reached.  gtk+
> > still seems stuck on gtk+-3.89, notwithstanding that gnome-3.24 has
> > now come out.
> >  
>
> I don't think there is any relation between GNOME releases and the
> development of GTK+ 4. As far as I know, version 3.89 is really v4
> alpha and will remain at that number until it's beta-worthy, at which
> point it will become 3.90 and so on.

I think you think incorrectly.  There is a relation: gnome components
will be encouraged to transition to gtk+-3.9* when it is out.  Whether
they do or not is another matter.  The rest of what you said seems OK.
_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list