Re: package version macros, pango backspace_deletes_character

["Ross McFarland" <rwmcfa1 neces com>]

Owen Taylor said:
> Let's go through the logic:
>
>  - If you actually care about application compatibility, you must have
>    some concept of API versions. I must be able to say that my Perl
>    program works with version 2.4.0 or newer of gtk2-perl.

$Gtk2::VERSION gives you what version of the bindings you're working with and
it has to have a format similar to 1.023, a legal perl version number.

>  - Using the version of GTK+ you compiled against as the API version
>    doesn't work because someone could always take an old version of
>    your perl binding and compile it against GTK+-2.8.

exactly right, that's why to really know you look at both $Gtk2::VERSION
(which tells you what could of been bound) and Gtk2->get_bound_verison_info
(which tells you what Gtk2 was compiled against)

>  - Using the version of GTK+ you compiled against also doesn't work
>    since that requires you to have the perl binding 100% complete
>    and perfect the first time you release it to the world.

not if you use the above two checks. if you know that support for the function
you need is in 1.021 of Gtk2, and it was implemented in gtk+ 2.2.0 you'd check
for those two things and then know you're safe.

>  - Using the installed version of GTK+ as the API version doesn't work
>    since the perl bindings might have been compiled against an older
>    version

this is why Gtk2->get_version_info is useless to perl app developers.

> So, the conclusion is that *you* have to take responsibility for
> providing an API version. And this means that you need to decide what
> version of GTK+ your bindings are for. You can't say "this version
> of the binding can be compiled for either GTK+-2.2 or GTK+-2.4."
>
> Since we don't plan to support GTK+-2.2 once a 2.4 release out I
> don't even see what the benefit of a dual compilation is.

so that people can get the lastest Gtk2 with as complete an api as we
currently have without having to upgrade gtk+.

> And for devel releases that compile against unstable releases of
> GTK+, those shouldn't show up as the "current" version of your
> module on CPAN anyways.

they don't. only the stable releases go on CPAN, but that's not the issue.

whatever release we have on CPAN has to support older gtk+'s, not just the
newest, or otherwise someone on a rh8/9 system can't install Gtk2 from CPAN.
they'd have to upgrade gtk+ first, that's not something we want to require
them to do. that's the kinda dependancies that make people give up when
installing an app. getting Gtk2 off of CPAN is a two minute exersize, if you
have to upgrade gtk+ first it becomes much more involved.

i won't argue if you think this is a mess, i do, but given the situation in
which we find ourselves it's the only way we've come up with to address all of
the issues.

reguardless this isn't an argument why there shouldn't be VERSION macros in
pango, if they've got a purpose in glib/gtk+ why wouldn't they serve the same
purpose in pango?

-rm