I would think this would be our problem. How bad is it going to look when an installed userbase gets shutdown due to a module that was changed just enough to break functionality in the P5EE(I thought Perl Enterprise Architecture sounded a bit bigger and better) modules.
I don't think we would need to write all of our own modules. Rather if we just have a seperate cpan like repository I think we would be fine. This way when a module gets updated on cpan, it gets the test suite ran with it. If the test suite still passes, then it is the new version that is shipped with P5EE. This doesn't resolve the issue of having users who upgrade packages on their own though. Scott On Wed, 24 Oct 2001, Robin Berjon wrote: > > * do we solve the wider problem of CPAN quality-control or an SDK, or > > just write the modules we need? > > No, that's not our problem. However, what we do want to do imho is to provide > a consistent world-view. For instance if P5EE must include some SOAP, then > we'd use SOAP::Lite behind the scenes but put the API into P5EE::SOAP which > would act as a wrapper pretending to be fully within the P5EE space and > providing consistent method names.
