[dancer-users] Dancer 1 and Dancer 2, what we're going to do

[Alexis Sukrieh]

http://www.sukria.net/fr/archives/2013/02/18/dancer-1-and-dancer-2-what-were-going-to-do/

Fellow Perl hackers, you who like to “dance“, read the following carefully
for I have some interesting news for you.

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.

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.

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.
Plugins can be migrated quite easily to support D1 and D2 at the same time.

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.

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.

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.

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:

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!)
Dancer 2 is released on CPAN and its ecosystem can rise
Dancer 1 users are happy
Dancer 2 users are happy
Migrating an app becomes something under control.
So, be prepared to see Dancer2 on CPAN pretty soon :)

And by the way, we’ll choose a Dancer 1 maintainer, because I won’t have
the time to handle both projects. Stay tuned!

Cheers,

    Alexis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.preshweb.co.uk/pipermail/dancer-users/attachments/20130218/a452f625/attachment.htm>