Thanks to you both for your input. I don't think the modules are quite similar enough to warrant the effort of writing a "wrapper" class around YAML::AppConfig, but I definitely like the idea of documenting a migration path from the deprecated to the actively maintained module.
m. On Thu, May 27, 2010 at 9:04 AM, Gabor Szabo <szab...@gmail.com> wrote: > On Thu, May 27, 2010 at 7:12 PM, David Precious <dav...@preshweb.co.uk> wrote: >> On Thursday 27 May 2010 16:44:58 Matt Grimm wrote: >>> The question is, how do I go about "retiring" one module on CPAN once >>> the merge is complete? I suppose the safest route might be to add a >>> big comment at the top of the retired module's Pod to indicate that it >>> is no longer maintained and users should start using the other module. >> >> That would seem to make sense. >> >> Depending on how similar the modules are, you might be able to release a >> skeleton YAML::AppConfig as a wrapper using Config::YAML to do the actual >> work, so that people already using YAML::AppConfig don't find their code >> suddenly breaking. >> >> That may be overkill though, and simply leaving the existing code (assuming >> it >> works well enough at the moment) with a "this is now deprecated, use >> Config::YAML which is actively developed" may be sufficient. >> > > IMHO it would be nice to provide a "migration path". A document, > or just a few examples on how to migrate from the deprecated > module to the new one. > > > Gabor >
