jkeroes/gist:5119626

## gistfile1.txt
Dancer2 - Revolution
Nothing indicated troubles, February 18, 2013 Alexis Sukrieh reports in his blog and in the newsletter dancer-users @ that will release Dancer2 as an independent project, and it will not replace the existing Dancer. February 22 at CPAN distribution Dancer2 appears to version 0.01.

Dancer2 originally created from scratch based Moo framework for Grease OOP system easy to extend and maintain. Mainly dealt with the new version of the problem - getting rid of the global variables and isolate the application from any potential conflicts. It also planned to provide 100% compatible with the Dancer, to be possible transparent migration of legacy applications and plug-ins for the new version of the framework.

In fact, since last fall has been frozen development Dancer and all the forces were sent back for revision Dancer2. But then it became clear that a transparent migration can not be performed primarily for technical reasons. Engines (engines) templating, sessions, logs differ significantly Dancer and Dancer2, since Dancer - this Perl 5 regular classes, which should be extended, and in Dancer2 - this role (Moo :: Role), which are connected. This technical problem has been obvious from the start. On the example of adaptation plug Dancer :: Template :: Xslate under Dancer2 I could see that the differences are so fundamental that keep the system in a state compatible plugins for different versions Dancer will be more complicated than simply issue a separate plugins for different versions of the framework. Moreover, setting engines in config.yml also have differences that completely breaks backward compatibility. Even assuming that some will be written Dancer2 wrapper to maintain backward compatibility, many real-world applications Dancer divided into multiple packets, and the scope of applications can be broken (no more global variables).

All this led to the realization that the evolutionary transition Dancer in Dancer2 not work and need to make a willful decision to separate ecosystems Dancer and Dancer2:

Dancer2 comes in its own namespace on CPAN and gives start their own ecosystem

Dancer thawed and development is directed on maintenance of the existing set of capabilities;
Dancer users happy;
Dancer2 users happy;
Application migration is now given control of the developer, who will decide he needs to make the transition or stay in the old system;
will be selected by a new maintainer of the project Dancer (for this position was chosen just two developers: Yanick Champoux and Alberto Simões).
Now there were first CPAN issues plugins Dancer2 and we can say that the revolution Dancer2 accomplished. But no reason to panic, the developers say that existing applications can continue to use Dancer, because its support does not stop. But starting to create new applications, it is preferable to choose Dancer2.

■ crux
	Dancer2 - Revolution
	Nothing indicated troubles, February 18, 2013 Alexis Sukrieh reports in his blog and in the newsletter dancer-users @ that will release Dancer2 as an independent project, and it will not replace the existing Dancer. February 22 at CPAN distribution Dancer2 appears to version 0.01.

	Dancer2 originally created from scratch based Moo framework for Grease OOP system easy to extend and maintain. Mainly dealt with the new version of the problem - getting rid of the global variables and isolate the application from any potential conflicts. It also planned to provide 100% compatible with the Dancer, to be possible transparent migration of legacy applications and plug-ins for the new version of the framework.

	In fact, since last fall has been frozen development Dancer and all the forces were sent back for revision Dancer2. But then it became clear that a transparent migration can not be performed primarily for technical reasons. Engines (engines) templating, sessions, logs differ significantly Dancer and Dancer2, since Dancer - this Perl 5 regular classes, which should be extended, and in Dancer2 - this role (Moo :: Role), which are connected. This technical problem has been obvious from the start. On the example of adaptation plug Dancer :: Template :: Xslate under Dancer2 I could see that the differences are so fundamental that keep the system in a state compatible plugins for different versions Dancer will be more complicated than simply issue a separate plugins for different versions of the framework. Moreover, setting engines in config.yml also have differences that completely breaks backward compatibility. Even assuming that some will be written Dancer2 wrapper to maintain backward compatibility, many real-world applications Dancer divided into multiple packets, and the scope of applications can be broken (no more global variables).

	All this led to the realization that the evolutionary transition Dancer in Dancer2 not work and need to make a willful decision to separate ecosystems Dancer and Dancer2:

	Dancer2 comes in its own namespace on CPAN and gives start their own ecosystem

	Dancer thawed and development is directed on maintenance of the existing set of capabilities;
	Dancer users happy;
	Dancer2 users happy;
	Application migration is now given control of the developer, who will decide he needs to make the transition or stay in the old system;
	will be selected by a new maintainer of the project Dancer (for this position was chosen just two developers: Yanick Champoux and Alberto Simões).
	Now there were first CPAN issues plugins Dancer2 and we can say that the revolution Dancer2 accomplished. But no reason to panic, the developers say that existing applications can continue to use Dancer, because its support does not stop. But starting to create new applications, it is preferable to choose Dancer2.

	■ crux