Thanks for the feedback! A few people have asked for a transition document like what you are asking for, I have yet to write it, but it is on my list.
The main thing for a darkpan maintainer to do is this: Run all your tests against the latest dev release on cpan ( https://metacpan.org/release/EXODIST/Test-Simple-1.301001_100). This can easily be done with a local::lob if you do not want to actually install it. If all your tests pass then there is nothing you need to do, everything just works. If this is the case please mention it somewhere, such as on this list. So far I have gotten only a handful of darkpan results, none of them reporting anything broken. It would be nice if there was a public list of darkpan results I can keep, and I may start one on github. If something is broken it would be best to send me a bug report on github. My goal is to break as little as possible, so if I do break something for you I would prefer fixing it over making you change you things. The only exceptions are when things are very crazy: Replacing the Test::Builder singleton, or breaking encapsulation by directly accessing hash keys of the Test::Builder object. The new stuff even goes so far as to support legacy monkeypatching of key methods in the Test::Builder namespace. -Chad On Sun, Apr 12, 2015 at 2:01 PM, Buddy Burden <barefootco...@gmail.com> wrote: > Chad, > > https://docs.google.com/document/d/1RCqf5uOQx0-8kE_ >> pGHqKSQr7zsJDXkblyNJoVR2mF1A/edit?usp=sharing >> >> Several people have asked for this, so I wrote it up. >> > > Excellent document. And, since I haven't said it yet, I applaud your > bravery for taking on this task. > > One thing I would like to see which I don't believe I've seen yet (or > perhaps I just missed it) is a some advice for the DarkPAN-ers out there. > If there were some sort of checklist that we could use to go through our > test suites ahead of time, I for one would love to go ahead and jump on > that. Something like: If your test suite infrastructure does X, then you > will need to change it to Y for the new system. Etc. Also, the solutions > would ideally be things that would work with both old and new, otherwise > getting the timing right may be tricky for many folks ... > > > -- Buddy >
