RE: RFC version issues

[Ross McFarland <rwmcfa1 neces com>]

On Fri, 2004-01-23 at 07:57, Murray Cumming Comneon com wrote:
> Because GTK+ never breaks ABI, there is no reason why people can't upgrade
> their GTK+ if they want to get new features or important bugfixes in newer
> version of gtk-perl.

other bindings can require upgrades of everything just to get bug fixes
for themselves if they wish, we haven't and aren't going to do that.
we're not putting the burden on users, the easier we make things the
better our bindings will be and the more they will be used.

> People will install gtk-perl from binaries. They will have no chance to do
> any fancy configure stuff anyway. And you don't want different distros doing
> different configure-time stuff so that each distro has gtk-perl binaries
> that seem to have the same number that have different APIs.

binaries are one of many ways people will install gtk2-perl. CPAN is
another (and most likely the primary method) and your suggested version
scheme wouldn't allow us to be on CPAN at all. or if it did we'd have to
a name space for each version Gtk2-2.0, Gtk2-2.2, Gtk2-2.4. and apps
would have to:

        use Gtk2-2.0; 
or
        use Gtk2-2.2; 
or
        use Gtk2-2.4; 

that's unreasonable. so basically unless CPAN (and perl) changes you can
drop trying to get us to change our version number scheme to match
gtk+/gnome/whatever.

besides are we are completely modular, are we supposed to match version
numbers for each module? gtk+ doesn't match gnome, pango doesn't match
anything else. for someone to upgrade they'd have to upgrade all of the
c libraries and then do pkg-config on each and every one of them, they
go grab matching numbers of our stuff to install. once again needlessly
putting the burden on our users.

> This works for everyone else, and should work for gtk-perl.
>
> [snip]
> > what does gtkmm does? this is/should be an issue for all of 
> > the binding sets not just gtk2-perl although i don't remember 
> > seeing anyone else even trying to handle it.  
>
> gtkmm 2.0.x works with GTK+ 2.0, 2.2 and 2.4. It has the same API however
> you configure it.
> gtkmm 2.2.x works with GTK+ 2.2 and 2.4. It has the same API however you
> configure it.
> gtkmm 2.4.x will work with GTK+ 2.4. It has the same API however you
> configure it.

if i run gtkmm 2.0.x with gtk+ 2.4 (as you say is supported) what does
get_version_info return to me? if it returns 2.4.x then apps written to
use specific features depending on get_version_info will fail b/c
they'll be getting that it's 2.4.x, but since they're running gtkmm
2.0.x the new features won't be bound. that's the issue here, not the
numbering scheme. 

this is the issue and it requires a specific solution. what does gtkmm
do to handle this? the two possibilities are those i outlined in the
original post, modify check_version and get_version_info or provide
alternatives. if one of the two hasn't been done then there's likely a
sizable problem with gtkmm (and any other bindings that aren't
addressing this) and version number have nothing to do with it and don't
protect you from it in the slightest.

in a perfect world a numbering scheme would be enough and when everyone
upgraded gtk+ they'd upgrade gtk2-perl, but that's not the case. we have
the ability to gracefully handle the situations and we will (through one
method or another,) but version numbers won't help do so. they'll only
give a false sense of compatibility. 

> We never had any complaints about that perfectly normal API policy.

we've never had complaints either, but that doesn't stop us from trying
to do things 'right' and prevent our users and developers from having
problems wherever/however their apps run. 

-rm