On 14 April 2017 at 17:52, Murray Cumming <murr...@murrayc.com> wrote: > > Glib 2.51/52 is meant to just target glib 2.51/52, with no API or ABI > break. glibmm-2.54 is the ABI-breaking API, which will be used with > gtkmm-4.0. It's not impossible that this will change again, I'm afraid. > > I'm not aware of any API/ABI breaks in glib. > > > Maybe then, based on this decision, that stuff should just be put in > > glibmm-2-50 anyway? > > I don't think there is any issue about where to put glib/glibmm API. > It's only unusual for GTK+/gtkmm.
My thought process was that now we have an allowance for adding/amending API in gtkmm-3-22, but I couldn't see an equivalent allowance for the 'stable' branch of glibmm. This assumes that the allowance for gtkmm also covers, e.g., fixing API that was incorrect or missing, not just maintaining parity with GTK+ and its own creative uses of the term 'stable'. Is that the case? If so, there are a few such patches that I have pushed to master and would love to see in 3.22 also. My next thought was that I have several, perhaps more, such patches for glibmm too - which as of now were only allowed into master. If patches like this were allowed in gtkmm (and I'll soon know the answer!), to me it would make sense if glibmm made the same allowance. I have most of these patches tagged on Bugzilla with the API tag, if that helps. I probably missed one or two, though.
_______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
