On version numbers

[Joe Schaefer <jo...@sunstarsys.com>]

With the mp2 rename and eventual release of
httpd 2.2, we have a new set of API/ABI issues 
to contend with.  The facts:

    1) being a system-wide library, libapreq2 
       will install in parallel with itself.
       How?  Simple- apr's major number is
       added to our soname's major number.

    2) mod_apreq2 installs into the modules 
       directory that apxs says it should go.
       If both httpd 2.0 and 2.2 share that
       directory it will collide, but that's
       ok.  2.2 is supposed to be an upgrade,
       so having only one mod_apreq2.so around
       is acceptible.

    3) The perl modules install into the
       Apache2:: and APR:: namespaces.  There
       can be only one of those per perl install,
       so collision always going to happen.

What we need is a versioning system that detects
the module-collisions at module load time.  The
server itself already has this built in, so (2)
is already taken care of. I think we only need to 
duplicate that feature for our perl modules.

Any opinions out there on how best to manage this?

-- 
Joe Schaefer

Re: On version numbers

[Joe Schaefer <jo...@sunstarsys.com>]

Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:

> Are you thinking of incompatibilities between the installed
> libapreq2, mod_apreq2, and the Perl modules? Or collisions
> just between different Perl module versions?

Both.  I'm thinking about situations where someone partially
upgrades an existing httpd 2.0 mp2 installation to 2.2.  Since 
it'spossible that 2.2 includes our C API, it's also possible 
that mod_apreq2 and libapreq2 get upgraded without upgrading 
the perl modules.  Assume this sequence for the sake of 
argument:

  1) $X installs mod_perl 2.0 + httpd 2.0.
  2) $X installs libapreq2, mod_apreq2 and our perl modules.
  3) $X upgrades their mod_perl installation to 2.2.  Assume
     2.2 ships with libapreq2 and mod_apreq2 only.

  4) $X starts their server, expecting our perl modules to work.
     How does $X discover that doesn't work?  Preferably, IMO,
     with an informative server log message.

> Related to this (but more for the benefit of 3rd party
> modules using apreq2), would adding an environment variable,
> such as mp2's MOD_PERL_API_VERSION, be of use?

No.
-- 
Joe Schaefer

Re: On version numbers

[Randy Kobes <ra...@theoryx5.uwinnipeg.ca>]

On Sun, 17 Apr 2005, Joe Schaefer wrote:

> With the mp2 rename and eventual release of
> httpd 2.2, we have a new set of API/ABI issues
> to contend with.  The facts:
>
>     1) being a system-wide library, libapreq2
>        will install in parallel with itself.
>        How?  Simple- apr's major number is
>        added to our soname's major number.
>
>     2) mod_apreq2 installs into the modules
>        directory that apxs says it should go.
>        If both httpd 2.0 and 2.2 share that
>        directory it will collide, but that's
>        ok.  2.2 is supposed to be an upgrade,
>        so having only one mod_apreq2.so around
>        is acceptible.
>
>     3) The perl modules install into the
>        Apache2:: and APR:: namespaces.  There
>        can be only one of those per perl install,
>        so collision always going to happen.
>
> What we need is a versioning system that detects
> the module-collisions at module load time.  The
> server itself already has this built in, so (2)
> is already taken care of. I think we only need to
> duplicate that feature for our perl modules.
>
> Any opinions out there on how best to manage this?

Are you thinking of incompatibilities between the installed
libapreq2, mod_apreq2, and the Perl modules? Or collisions
just between different Perl module versions?

Related to this (but more for the benefit of 3rd party
modules using apreq2), would adding an environment variable,
such as mp2's MOD_PERL_API_VERSION, be of use?

-- 
best regards,
randy