<div dir="ltr"><div style><a href="http://www.sukria.net/fr/archives/2013/02/18/dancer-1-and-dancer-2-what-were-going-to-do/">http://www.sukria.net/fr/archives/2013/02/18/dancer-1-and-dancer-2-what-were-going-to-do/</a><br>
</div><div><br></div><div>Fellow Perl hackers, you who like to “dance“, read the following carefully for I have some interesting news for you.</div><div><br></div><div>You probably know that we’ve frozen Dancer 1 development some time ago, when we decided to focus all the energy on Dancer 2. That was done with an idea in mind: get the most possible out of the D2 prototype.</div>
<div><br></div><div>We had also the idea that D2 will at some point be able to replace D1. Entirely. It was a mistake. Actually a mistake that will lead to something that I believe is rather very good for the Dancer community, let me explain.</div>
<div><br></div><div>Dancer 2 is a success on many fields: it’s entirely written with Moo, so it has a complete OO layer. The core encapsulates each app in a proper instance, ensuring no more app collisions will occur. All the non-deprecated keywords of the DSL provided by Dancer 1 are supported in Dancer 2. Some components are even better in D2 (look at the awesome session handling for instance) and the Moo layer behind the scene allows many great things for the future.</div>
<div>Plugins can be migrated quite easily to support D1 and D2 at the same time.</div><div><br></div><div>But there is one thing that won’t be possible: support engines in D1 and in D2 transparently. The reason is rather technical: in D1, an engine (logger, template, session) is a class that should be extended (in pure Perl 5 code). In D2, it’s a role that should be composed. Of course, the design is more rigid, and many things need to be changed for an engine to work under D2.</div>
<div><br></div><div>The question was: should we spend energy on trying to support both? Should we provide a wrapper to allow easy migration? The consensus is no. We’ll do something else.</div><div><br></div><div>There is out there a lot of real-life D1 applications. Most of them use engines that won’t work transparently under D2. Also the app-scoping can break things with some applications, if the app is decoupled in many packages.</div>
<div><br></div><div>For that reason, I’m going to release Dancer 2 in its own namespace, and that will bring a lot of energy in both projects:</div><div><br></div><div>Dancer 1 is at the same time unfrozen, development can continue there (as long as the features added are not something that would lead to a new Dancer 2!)</div>
<div>Dancer 2 is released on CPAN and its ecosystem can rise</div><div>Dancer 1 users are happy</div><div>Dancer 2 users are happy</div><div>Migrating an app becomes something under control.</div><div>So, be prepared to see Dancer2 on CPAN pretty soon :)</div>
<div><br></div><div>And by the way, we’ll choose a Dancer 1 maintainer, because I won’t have the time to handle both projects. Stay tuned!</div><div><br></div><div style>Cheers,</div><div style><br></div><div style>    Alexis.</div>
</div>