perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: dependency in Apache2::Status
Date Wed, 16 Mar 2005 00:50:12 GMT

> The problem before us now is basically this: how do we extract the old 
> "generations" concept *out of* the installation layout (ie MP_INST_APACHE2)
> and incorporate it directly *into* the runtime?  Remember, we didn't have a 
> minor-number gradation for the layout (after all, it wasn't,
> so we shouldn't *need* one for what we're trying to do with the runtime.
> If you see a future advantage to exposing a minor API number, please 
> expain that.

yes, it was thoughts about the future, but nothing I can concretely
pinpoint.  I guess what I saw the possibility of was people using this new
API variable as a way to distinguish, say, which form of Apache2::Foo->bar()
to call.  but they can just as easily do that with $mod_perl::VERSION I

> Remember what we decided in the pmc: 
>          1) mp2 will install in parallel with mp1,
>          2) future mp2 releases will supercede prior mp2 releases,
>          3) whoever is doing mp3 will get to decide what to do 
>             about the existing mp1 & mp2 codebases, when that time comes.

yeah, I wasn't trying to achieve a 2.0 versus 2.1 versus 3.0 level of
granularity.  it was more users being able to say "ah, 2.13 was the minor
bump that changes things important to our app" and having $bump be a simple
integer comparison, versus saying the same thing about 2.002_14-dev.

but don't worry, I'm not all that concerned about all of this - you asked me
to explain so I did :)

>>so, I dunno.  perhaps we don't need the full major/minor bits a la
>>httpd, but something between "2" and "20050315.12"
> +1 for putting a plain-old "2" in any $ENV{MOD_PERL_FOO} you like best.

ok, that's fine with me.  others should feel free to weigh in as well, though :)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message