This is a discussion on Re: What happened with Apache2::Reload in mod_perl-2.0.4? - modperl ; This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE628C3F319E1F6DC33B23A69 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Fred Moyer wrote: > Geoffrey Young wrote: >> >> Fred Moyer wrote: >>> Niels van Dijke wrote: >>>> Hi mod_perl maintainers, >>>> >>>> ...
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Fred Moyer wrote:
> Geoffrey Young wrote:
>> Fred Moyer wrote:
>>> Niels van Dijke wrote:
>>>> Hi mod_perl maintainers,
>>>> Thank you for releasing mod_perl 2.0.4.
>>>> I was wondering what happened to Apache2::Reload? Was it missed in
>>>> packaging for the upload to CPAN? If so then there may be other file=
>>>> missing too.
>>> See the Changelog:
>>> Apache2::Reload has been moved to an externally maintained
>>> CPAN distribution
>> I can't remember if I knew this or not, but we probably ought to treat=
>> this like Apache-Test: keep bundling it with releases _and_ maintain=20
>> something separate on CPAN.
> That's on the radar for 2.0.5, along with Apache::SizeLimit, to bundle =
> using svn:external. Phillip Gollucci brought this up about a month ago=
> or so, and I started to move on it but Gozer brought up a number of=20
> things that had to be done to make this happen and the works with 5.10 =
> release was pressing at that point.
> Don't worry, I won't forget about it
>> so I guess this means a mp2 release should (going forward) include _an=
>> imply a new release of
>> o mp2
>> o Apache-Test
>> o Apache-Reload
And as the latest Release Manager, I must say that having to release 3
extra CPAN modules along with each mp2 releases is going to be a PITA.
THat way, 2 things happen. First, we can always release mod_perl, without=
having to worry about these external packages. We know what we are bundli=
is exactly the same stuff that is _already_ on CPAN, great. Second, mod_p=
itself is protected from spurious failures caused by changes in any of th=
modules before they are released.
The only negative is that if a change is made to say Apache-Test to fix a=
problem mod_perl needs/wants, it complicates things a little. I make the
fix in A-T, making sure it fixes mod_perl's problem. If sure of that,
I proceed to release A-T. Once released, I can now test mod_perl against
this new A-T by locally changing the tag the svn:external is pointing to,=
and if it solves to problem and doesn't create new ones, checkin the new
I've dealt with 3rd packages in this way plenty, and it works.
Anyhting terribly obvious I am missing here ?
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----