Re: [pygtk] pygobject matching glib version numbers
> Yes, we agreed on synchronizing with the glib version number but we > have not done any release since then. > > On monday we'll be releasing 2.26.0, will bump it now in git. I see this has been done now, thanks a lot! Sorry to pester, John ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] pygobject matching glib version numbers
On Sun, Sep 26, 2010 at 00:48, John Stowers wrote: > On Wed, 2010-08-11 at 10:07 +0200, Tomeu Vizoso wrote: >> Hi, >> >> John Stowers has proposed that PyGObject changes it's version >> numbering to match that of glib. This means that the next stable >> version will be 2.26 instead of 2.22. >> >> The rationale is that it will help people a bit to know what to expect >> from a given PyGObject release. He's already numbering his PyGtk >> releases matching Gtk+ versions. >> >> If nobody has good reasons against, the next unstable release of >> PyGObject will be 2.25.1. > > Hi, > > I noticed that this hasn't been done yet despite agreement. Would it be > OK if you or John P. bumped the version before release? Yes, we agreed on synchronizing with the glib version number but we have not done any release since then. On monday we'll be releasing 2.26.0, will bump it now in git. Regards, Tomeu > John > >> >> Regards, >> >> Tomeu >> ___ >> python-hackers-list mailing list >> python-hackers-l...@gnome.org >> http://mail.gnome.org/mailman/listinfo/python-hackers-list > > > ___ > python-hackers-list mailing list > python-hackers-l...@gnome.org > http://mail.gnome.org/mailman/listinfo/python-hackers-list > ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] pygobject matching glib version numbers
On Wed, 2010-08-11 at 10:07 +0200, Tomeu Vizoso wrote: > Hi, > > John Stowers has proposed that PyGObject changes it's version > numbering to match that of glib. This means that the next stable > version will be 2.26 instead of 2.22. > > The rationale is that it will help people a bit to know what to expect > from a given PyGObject release. He's already numbering his PyGtk > releases matching Gtk+ versions. > > If nobody has good reasons against, the next unstable release of > PyGObject will be 2.25.1. Hi, I noticed that this hasn't been done yet despite agreement. Would it be OK if you or John P. bumped the version before release? John > > Regards, > > Tomeu > ___ > python-hackers-list mailing list > python-hackers-l...@gnome.org > http://mail.gnome.org/mailman/listinfo/python-hackers-list ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] pygobject matching glib version numbers
On 08/11/2010 06:04 AM, John Stowers wrote: > On Wed, 2010-08-11 at 11:44 +0200, Simon van der Linden wrote: >> On Wed, 2010-08-11 at 11:08 +0200, Tomeu Vizoso wrote: >>> On Wed, Aug 11, 2010 at 10:57, Simon van der Linden >>> wrote: On Wed, 2010-08-11 at 10:07 +0200, Tomeu Vizoso wrote: > The rationale is that it will help people a bit to know what to expect > from a given PyGObject release. He's already numbering his PyGtk > releases matching Gtk+ versions. I wonder whether it makes sense for PyGObject, which is not, to my knowledge, a set of static binding for GLib. We don't exactly ensure that all the features available in the matching GLib version is available to Python developers, do we? >>> >>> I think that's something we should aim for. I also consider g-i to be >>> a logical part of GLib even if it hasn't been merged yet. >> >> I'm neither in favor nor against this change. I think it will not bring >> anything. > > I have lost track of the number of times I have had to explain the > versions of Gtk, PyGtk, Glib and PyGObject to people trying to get stuff > to work on windows, and every time noted that the version mismatches > were unhelpful, confusing and often resulted in them trying > build/runtime combinations that did not work. I'm not on most of the cc:d lists, so this might bounce. I have this exact problem. I try a bunch of build/runtime combinations until I find one that works. Even if the version number scheme doesn't change so that things match, there should at least be a table somewhere that tells you which version of the bindings goes with which version of the bound library. If such a thing already exists for PyGtk and PyGObject, I'd love to know where it is. /will ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] pygobject matching glib version numbers
On Wed, 2010-08-11 at 11:08 +0200, Tomeu Vizoso wrote: > On Wed, Aug 11, 2010 at 10:57, Simon van der Linden > wrote: > > On Wed, 2010-08-11 at 10:07 +0200, Tomeu Vizoso wrote: > >> The rationale is that it will help people a bit to know what to expect > >> from a given PyGObject release. He's already numbering his PyGtk > >> releases matching Gtk+ versions. > > > > I wonder whether it makes sense for PyGObject, which is not, to my > > knowledge, a set of static binding for GLib. We don't exactly ensure > > that all the features available in the matching GLib version is > > available to Python developers, do we? > > I think that's something we should aim for. I also consider g-i to be > a logical part of GLib even if it hasn't been merged yet. I'm neither in favor nor against this change. I think it will not bring anything. In the long term, I think following GNOME's version number (i.e. 2.31.x for now), both for PyGObject and GLib (and G-I, thus) would make more sense. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] pygobject matching glib version numbers
On Wed, 2010-08-11 at 11:44 +0200, Simon van der Linden wrote: > On Wed, 2010-08-11 at 11:08 +0200, Tomeu Vizoso wrote: > > On Wed, Aug 11, 2010 at 10:57, Simon van der Linden > > wrote: > > > On Wed, 2010-08-11 at 10:07 +0200, Tomeu Vizoso wrote: > > >> The rationale is that it will help people a bit to know what to expect > > >> from a given PyGObject release. He's already numbering his PyGtk > > >> releases matching Gtk+ versions. > > > > > > I wonder whether it makes sense for PyGObject, which is not, to my > > > knowledge, a set of static binding for GLib. We don't exactly ensure > > > that all the features available in the matching GLib version is > > > available to Python developers, do we? > > > > I think that's something we should aim for. I also consider g-i to be > > a logical part of GLib even if it hasn't been merged yet. > > I'm neither in favor nor against this change. I think it will not bring > anything. I have lost track of the number of times I have had to explain the versions of Gtk, PyGtk, Glib and PyGObject to people trying to get stuff to work on windows, and every time noted that the version mismatches were unhelpful, confusing and often resulted in them trying build/runtime combinations that did not work. This is less the case on linux where your distribution/package manager hides it from you. John ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] pygobject matching glib version numbers
On Wed, 2010-08-11 at 11:08 +0200, Tomeu Vizoso wrote: > On Wed, Aug 11, 2010 at 10:57, Simon van der Linden > wrote: > > On Wed, 2010-08-11 at 10:07 +0200, Tomeu Vizoso wrote: > >> The rationale is that it will help people a bit to know what to expect > >> from a given PyGObject release. He's already numbering his PyGtk > >> releases matching Gtk+ versions. > > > > I wonder whether it makes sense for PyGObject, which is not, to my > > knowledge, a set of static binding for GLib. We don't exactly ensure > > that all the features available in the matching GLib version is > > available to Python developers, do we? > > I think that's something we should aim for. I also consider g-i to be > a logical part of GLib even if it hasn't been merged yet. I'm neither in favor nor against this change. I think it will not bring anything. In the long term, I think following GNOME's version number (i.e. 2.31.x for now), both for PyGObject and GLib (and G-I, thus) would make more sense. Regards, Simon ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] pygobject matching glib version numbers
On Wed, Aug 11, 2010 at 10:57, Simon van der Linden wrote: > On Wed, 2010-08-11 at 10:07 +0200, Tomeu Vizoso wrote: >> The rationale is that it will help people a bit to know what to expect >> from a given PyGObject release. He's already numbering his PyGtk >> releases matching Gtk+ versions. > > I wonder whether it makes sense for PyGObject, which is not, to my > knowledge, a set of static binding for GLib. We don't exactly ensure > that all the features available in the matching GLib version is > available to Python developers, do we? I think that's something we should aim for. I also consider g-i to be a logical part of GLib even if it hasn't been merged yet. It's true PyGObject doesn't aim to be a set of static bindings in the same way that PyGtk does, but then GLib has lots of infrastructure stuff that doesn't make sense to expose to Python as-is. In summary, while PyGObject won't try to wrap every bit of GLib, it should aim to expose to Python all the functionality that makes sense, for each version. Regards, Tomeu > Regards, > > Simon > > > ___ > python-hackers-list mailing list > python-hackers-l...@gnome.org > http://mail.gnome.org/mailman/listinfo/python-hackers-list > ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] pygobject matching glib version numbers
On Wed, 2010-08-11 at 10:07 +0200, Tomeu Vizoso wrote: > The rationale is that it will help people a bit to know what to expect > from a given PyGObject release. He's already numbering his PyGtk > releases matching Gtk+ versions. I wonder whether it makes sense for PyGObject, which is not, to my knowledge, a set of static binding for GLib. We don't exactly ensure that all the features available in the matching GLib version is available to Python developers, do we? Regards, Simon ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
