Re: package version macros, pango backspace_deletes_character

[Owen Taylor <otaylor redhat com>]

On Tue, 2004-02-03 at 10:54, Ross McFarland wrote:

> > But I think trying to support multiple versions is almost always a bad
> > idea.  It means that someone using version X.Y.Z of your binding
> > has *NO IDEA* what Pango functions it supports ... it will completely
> > depend on version of Pango was installed when the Perl binding was
> > compiled.

[...]

> bascially we compile in everything avaible at build time. since CPAN only lets
> us have 1 current release for a given module namespace we have to have support
> for every level in that single release, if we're going to have support for new
> stuff anywhere. trying to have version sync'd rels wouldn't buy us anything
> b/c you could get gtk2-perl 2.4.0 and compile it against gtk+ 2.2.0 and then
> later upgrade gtk+ to 2.4.0 and then think you'd have support that you didn't.

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.

 - 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.

 - 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.

 - 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 

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.

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.

Regards,
						Owen