Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3F86FDAB.10000@stason.org>
Date: Fri, 10 Oct 2003 11:42:51 -0700
From: Stas Bekman <stas@stason.org>
Organization: Hope, Humanized
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
MIME-Version: 1.0
To: Joe Schaefer <joe+gmane@sunstarsys.com>
Cc: apreq-dev@httpd.apache.org
Subject: Re: clarification? Re: [VOTE] apreq-2 versioning system
References: <m38ynzpqip.fsf@sol.sunstarsys.com>
 <m365ixnqw3.fsf@sol.sunstarsys.com> <3F86EB31.80009@stason.org>
 <m31xtlneob.fsf@sol.sunstarsys.com>
In-Reply-To: <m31xtlneob.fsf@sol.sunstarsys.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Joe Schaefer wrote:
> 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.

Sorry, I wasn't clear what I was talking about. I meant that versioning in the 
Changes file. Currently we have in httpd-apreq/Changes:

=item 1.30 - September 27, 2003

libapreq-1.3 is released.

Here the Changes version doesn't match release version, should have been 
libapreq-1.30.

>>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.

Let's say that the libapreq package version is unrelated to either of the .pm 
files.

Normally, a version number is not bumped up on each fix, but only during the 
release time. So may be the following will work?

Independently for Request.pm and Cookie.pm, bump up each ones version number 
just before doing a realy, if and only if, that file has changed from the 
previous release? So if Request.pm was at version 2.01 and it hasn't changed 
between apreq releases 2.09 and 2.10, it should have the same version as 
before. If Cookie.pm was at version 2.05 and was changed several times since 
apreq-2.09, its version should be 2.06 when apreq-2.10 is released. Does this 
sound good? Or should the version of .pm files be bumped up on each commit to 
that file?

Another approach is not to maintain these package numbers at all, instead 
require users to work with Apache::libapreq2 which will maintain a single 
version number for all .pm files and match libapreq's distro number. I think 
that'd be the simplest solution.

>>>       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.

You mean, in httpd-apreq (1)? I can't find it in httpd-apreq-2:

   httpd-apreq-2> find . | grep libapreq.pm

gives nothing.

>>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.

sure


__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com