Module upgrades that move from XS to PP?

Question: if a module started it's life with XS components and a subsequent
upgrade removes those components and makes the module pure-perl, then is
there any mechanism to ensure that the new version is loaded?

In @INC, the architecture specific directories always come before the non-
specific dirs.  Take a module like SQL::Statement.  When it moved from v0.1021
to v1.0, it lost it's XS components.  So the main module moved living here:

$Config{sitearch}/SQL/Statement.pm

to here:

$Config{sitelib}/SQL/Statement.pm

But because of @INC ordering, the old architecture specific version will
always be loaded first.

In an environment where module upgrades are zipped up and overlaid on top of
the old module, is there any automatic way to detect this kind of problem?
Unless the consumers of the module specify a version number when the 'use' the
module, no errors will even be reported until the consumer tries to use
new or backwards-incompatible functionality, when strange and weird errors
will show up.

The best solution I can see right now is to ensure that all old files of a
distribution are deleted prior to overlaying the new module into sitelib, but
this requires that an accurate list of all files installed in the past be
available, which isn't always the case.

I don't see any simple solution to this other than to be extra vigilant when
upgrading, and hoping that the module author points out this subtle gotcha in
the ChangeLog of their module.

Any thoughts to the contrary are welcome.

-- 
j.
 
James FitzGibbon
TTS Distribution Development
612-375-2307
 

• Module upgrades that move from XS to PP? by James.FitzGibbon
• Re: Module upgrades that move from XS to PP? by schwern
• Re: Module upgrades that move from XS to PP? by Nick Ing-Simmons