httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: clarification? Re: [VOTE] apreq-2 versioning system
Date Fri, 10 Oct 2003 18:14:12 GMT
Stas Bekman <stas@stason.org> writes:

> Joe Schaefer wrote:
> [...]
> 
> Before I vote, there are a few issues with the perl glue.
> 
> > for the perl glue-
> >        1) Apache::Cookie and Apache::Request will be versioned
> > starting from 2.0.  This will likely cause pain for 1.3
> >           users that set their dependency requirements based on
> >           Apache::Request's version instead of libapreq's.
> 
> hopefully, this generation won't have its versions mismatching the
> release versions (in 1.x we had 1, 1.1, 1.2), 

Which did match the release versions for 1.x, didn't they?

> whereas here we probably want to have 2.00, 2.01, ... 2.15 etc.

To clarify: in 1.x the version numbers for the perl modules always
matched the *package* release number.  So what you're saying is that we
should stick to this policy, but be sure to use 2.xx (two-digits for
the minor number) instead?  If so, that's fine with me.

> Also should Apache::Request's version be the only one that has
> $VERSION and use that for the release version?

Do you see an advantage in that?  If we're syncing the perl module
versions with the package release version, I don't see any benefit
in maintaining that policy for just Request.pm and not Cookie.pm.  
Remember these modules do not depend on one another in apreq-1, nor in
apreq-2.

> 
> >        2) Apache::libapreq will be renamed Apache::libapreq2, and should
> >           make the same installation info available that the
> > apreq2-config script does.
> 
> rename? Do we have already Apache::libapreq?

We do.

> What's important is that Apache::libapreq2 is needed only for CPAN module
> dependecies. It shouldn't contain any code and shouldn't be really
> used in the modules. 

Right- just like in the 1.x versions, it should be pure perl module just
to locate config/install data for building other perl modules that want
to interface with libapreq somehow (roughly equivalent to apreq2-config
+ some additional config info - i.e. typemaps - for reusing the perl 
glue).

> Why? Because ideally a program working with libapreq1 should work the
> same with libapreq2. Similarly, in mod_perl2 we have Apache2.pm, which
> you can require in MakeMaker for mp2 and Apache.pm for
> mp1. Incidentally, since mp1 and mp2 aren't compatible each of these
> modules contain code, but as suggested ideally for apreq it'd be good
> not to depend on libapreq.pm or libapreq2.pm in the code itself.

Yup, +1.  The bulk of the perl API of Apache::Request and Apache::Cookie
should be source compatible with the 1.x versions.  However, the matchup
isn't perfect, and authors that must demand a compatible API (1.x or
2.xx) for their application need to be able to do that.  Food for
thought- there may come a time when someone contributes an apache-1.3
module for libapreq2, in which case folks can use our 2.X API for both
mp1 and mp2.
-- 
Joe Schaefer


Mime
View raw message