RE: RFC version issues

[Ross McFarland <rwmcfa1 neces com>]

On Fri, 2004-01-23 at 04:15, Murray Cumming Comneon com wrote:
> It sounds like gtk-perl compiles different stuff depending on what version
> of the dependencies are available. This does sound very confusing. I think
> that version x of gtk-perl (or anything) should have the same API and always
> the same API. If people want GTK+ 2.2 instead of GTK+ 2.4 then they can use
> an older version of gtk-perl.

that would be more confusing than anything. we'd have to have a stable
release for each and every gtk level. and every time there was a bug fix
we'd have to do it in every one of them. people aren't used to grabbing
a matching version of something they're used to grabbing the highest.
we'd have to have release like 2.0.6-1.0 and 2.0.6-1.2 etc. for bug
fixes and it's likely that the -x.x part would be different for
different levels of gtk+ as support for things was added and bugs fixed
that only affected some of the support levels.

that it would be a nightmare to try to keep all of the matching stuff
straight, right now #ifdef's do it for us.

beyond that matching version numbers doesn't enforce/protect against
this issue. the things that i'm talking about here would still be
necessary. in fact matching version numbers would be no help at all. you
can't expect a sysadmin (or user) to know that if they upgrade gtk+ and
friends that they have to know that now they need to upgrade to a
matching version number of gtk2-perl. the chances are that when they
upgrade gtk+ gtk2-perl won't even cross their mind. and they'll still
have apps around that use 2.0.6-1.2 against the newly installed 2.4.0
gtk+. which wouldn't be a problem from a running standpoint, but now an
app that does version checking thinks it has 2.4.0.

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.  

-rm