Mailing-List: contact test-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: test-dev@httpd.apache.org
Message-ID: <40C85C8A.6010804@stason.org>
Date: Thu, 10 Jun 2004 06:05:14 -0700
From: Stas Bekman <stas@stason.org>
Organization: Hope, Humanized
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115
MIME-Version: 1.0
To: test-dev@httpd.apache.org
Subject: Re: switching t_cmp() argument order
References: <200406072056.i57Kurx5024931@moya.tamu.edu>
 <40C50F27.7020804@modperlcookbook.org> <40C5BDA2.5030807@stason.org>
 <40C61A0B.4030801@modperlcookbook.org> <40C71DE4.7080704@stason.org>
 <40C728A2.2040805@modperlcookbook.org> <40C72E40.1030604@stason.org>
 <40C76A17.5000507@modperlcookbook.org> <40C8223F.9080700@stason.org>
 <40C8566A.8080509@modperlcookbook.org>
In-Reply-To: <40C8566A.8080509@modperlcookbook.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Geoffrey Young wrote:
> 
> Stas Bekman wrote:
> 
>>Geoffrey Young wrote:
>>
>>
>>>>But it's quite possible that argument could be readonly while not a
>>>>string, a simple example is a return value of a function:
>>>>
>>>>% perl -le 'a(b(), "b"); sub a {($_[0], $_[1]) = ($_[1], $_[0]);}; \
>>>>           sub b { 5 }'
>>>>Modification of a read-only value attempted at -e line 1.
>>>
>>>
>>>
>>>I think you need to revisit that example :)
>>
>>
>>I fail to see what do you mean.
> 
> 
> perl -le 'a(b(), c()); sub a {($_[0], $_[1]) = ($_[1], $_[0]);}; \
>   sub b{5}; sub c{6};

I still don't get it. What are you trying to say?

>>>ok, the attached patch reflects that.
>>
>>
>>excellent!
>>
>>the only remaining nit is the deprecation cycle, let's say we happen to
>>release the next few versions within this month, then you hit 1.15
>>really soon. I think it's a matter of time and not release numbers. So
>>may be it's better to say, let's give people some 3 months to move over
>>and set a certain date as a cutoff rather than a version number? Just an
>>idea...
> 
> 
> sure, we could do that, but then the cutoff isn't really clear.  I think
> that three revisions will get us through at least another mod_perl release,
> when people are perhaps likely to glance at the Changes file.
> 
> but if we need more time I think we can take it.  if the deprecation cycle
> is very long (like 3 new releases takes us a year) I don't think that's
> necessarily a bad thing.

Not for Apache-Test. There will be lots of new mp2 releases in the next few 
months to come. Once the API is completed and a few remaining release issues 
resolved we will start doing release candidates. So as long as we do at least 
one tweak to A-T between these releases I promise you A-T 1.15 before the end 
of the summer.

> but either way is fine.  I just didn't want it removed in, say, the release
> after the next one.

just add a line like, remove after Sep 15th or so. and may be take it into
if ($deprecated) { ...}
so it's easy to remove the whole branch at once without thinking too much.

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