> [...nice work!...]
:)
> I'm curious why we want to create a "module-magic-number" like the
> $API_VERSION you've got here. Does it convey any useful information
> beyond what's already in $VERSION?
not really. I guess I thought it was somewhat easier to parse than the
current $VERSION is all.
>
> Hmm, perhaps you are trying to kill two birds with one stone here
> (mp1-back-compat and future ABI changes in the httpd 2.x line)?
> If so, I think httpd handles ABI changes all by itself, by refusing
> to even load ABI-incompatible modules.
well, I was thinking abi on from an perl or xs pov, which httpd wouldn't
cover. but I guess you're right.
>
> As far as CGI.pm is concerned, it doesn't need this level of detail;
> it just needs to know which mod_perl module to require.
yes.
> An
> "generation" integer would probably suffice for that (or even my old
> "exists $ENV{MOD_PERL2}" idea). IOW, here's my +1 for making the
> patch set $ENV{MOD_PERL_API_VERSION} = 2 (or MOD_PERL_GENERATION
> if you prefer).
well, if we go that route I don't think we need anything beyond guaranteeing
that $ENV{MOD_PERL} is not only true, but will contain the version from here
on out. but the idea I had was to present something that was clear and easy
to parse that modules could rely on going forward, the thought being that
"mod_perl/1.999_21-dev" wasn't nearly as clear or simple as "2.1" where 2
was some major revision (like mp2) and 1 was some minor API ideal.
so, I dunno. perhaps we don't need the full major/minor bits a la httpd,
but something between "2" and "20050315.12"
?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
