adam.prime at utoronto
Apr 20, 2012, 11:49 AM
Views: 618
Permalink
|
|
Re: [RELEASE CANDIDATE]: mod_perl-2.0.5 RC5
[In reply to]
|
|
Committed revision 1328477.
Adam
On 12-04-20 11:15 AM, Fred Moyer wrote:
> +1 for this fix. Adam, if you want to apply it, I'll roll RC6.
>
> On Fri, Apr 20, 2012 at 8:13 AM, Adam Prime<adam.prime [at] utoronto> wrote:
>>> #if defined(__GNUC__)&& !defined(PERL_GCC_BRACE_GROUPS_FORBIDDEN)
>>
>>> # define MUTABLE_PTR(p) ({ void *_p = (p); _p; })
>>> #else
>>> # define MUTABLE_PTR(p) ((void *) (p))
>>> #endif
>>>
>>> So the solution for the problem is simple:
>>>
>>> # ifdef MUTABLE_SV
>>> SV *sv=MUTABLE_SV(...);
>>> # else
>>> SV *sv=(SV*)...
>>> # endif
>>>
>>
>> This fixed the problem i was having, and all the tests pass. the patch I
>> used to the rc5 tree source is attached. it'll probably have to be poked
>> with to apply to svn.
>>
>> Because the solution to this particular issue appears to be this simple, I
>> think that it might be in our best interest to do rc6 with this change, and
>> explicitly say we aren't going to support whatever we aren't going to
>> support for the next release. I am more than willing to be overruled on
>> this though ;)
>>
>> Adam
>>
>>
>>
>>
>>
>>
>>
>> On 12-04-20 06:27 AM, Torsten Förtsch wrote:
>>>
>>> On Thursday, 19 April 2012 18:45:59 Fred Moyer wrote:
>>>>>
>>>>> Apparently MUTABLE_CV doesn't exist under 5.8.8
>>>>
>>>>
>>>> Verified. Thoughts? +1 to ship as is. 5.8.8 isn't being shipped with
>>>> any new Linux or other OS distributions as far as I know.
>>>
>>>
>>> I think the central question is how many perl versions back we want to
>>> support. This has been discussed a few times already. Perl itself has
>>> settled
>>> on support for the current stable version plus one back. Current stable is
>>> 5.14. So, they support 5.14 and 5.12. But support for 5.12 will end soon
>>> as
>>> 5.16 is approaching. See L<perlpolicy>.
>>>
>>> As for modperl, I am not sure if we should bind our compatibility policy
>>> to a
>>> fixed number of perl/httpd versions. But something like "for 2.0.7 we are
>>> dropping support for perl versions older than 5.12, httpd versions older
>>> than
>>> ... and APR versions older than ..." in the beginning of the dev cycle
>>> would
>>> be good. Then we have to make sure that trunk is tested against the
>>> supported
>>> versions on a regular basis. Or perhaps we should make it a white list
>>> like
>>> 2.0.7 will support perl 5.12 .. 5.16, httpd 2.2.x, apr 1.4.x. Modperl 2.1
>>> will
>>> support perl ..., httpd 2.4.x, ...
>>>
>>> If we cannot assure testing trunk against those versions regularly we must
>>> change that statement *before* RC1 is rolled.
>>>
>>> Producing release candidates is someone's work and time. Testing them is
>>> so,
>>> too. I understand that there must be a RC(n+1) if RCn introduced a bug
>>> while
>>> fixing another. But if RCn (with say n>2) has a compatibility issue that
>>> comes
>>> up only because modperl was first tested in the environment at that stage
>>> I
>>> think that does not qualify for another RC.
>>>
>>> If the interest in 5.8.8 compatibility is great enough to fix the issue (I
>>> don't say it is a bug) and Fred wants to roll another RC I'll test it. But
>>> IMHO RC5 is good enough to be 2.0.6.
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe [at] perl
>> For additional commands, e-mail: dev-help [at] perl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl
|
