POE 0.2302 is the first release candidate for 0.24, so please report problems early and often. Instructions for finding it are at the usual location: http://poe.perl.org/?Where_to_Get_POE
The main thrust, if you will, of the changes leading to version 0.24 has been to improve the clarity and extensibility of POE's implementation. Very few of these changes are visible to the casual user despite their pervasive nature. Things which are different in 0.2302: - Scheduled deprecations have been moved forward. Event handlers that handle signals with return values will generate warnings. _signal handlers will generate warnings. FooState parameters for Wheel classes have been upgraded from warnings to errors. - The TRACE_FOO and ASSERT_FOO constants have been standardized. The messages they generate are standardized and cleaned up. Environment variables (POE_TRACE_FOO and POE_ASSERT_FOO) let developers toggle debugging information without editing files. That concludes the most visible changes to POE. The remainder will be most useful for POE's developers and people who would like to work on the project. - POE's event loop bridges are simplified, and the interface they share has been standardized. The bridge classes have been renamed from POE::Kernel::* to POE::Loop::*. - POE::Loop was created as the abstract base class for event loop bridges. It documents the bridge interface and can be used as a design guide for new ones. - POE's event queue is very stable, so the code was extracted into POE::Queue::Array. POE::Kernel developers can more easily ignore it. - POE::Queue was created as the abstract base class for queue strategies. It documents the queue strategy interface and can be used as a design guide for new ones. - Macros have almost entirely been replaced by function calls. This makes the code more readable and maintainable by people who don't know POE::Preprocessor. It also increases POE's modularity, making it easier to create XS versions of various subsystems. - POE::Kernel's public interface code has been split from the internal data manipulation code. New interfaces may be added and can share back-end implementations, and the data management code can be moved to separate modules and tested in units. - POE's tests were extended with the tests from POE::Component modules on the CPAN. POE's code coverage is higher. Guts hackers can test whether changes break other modules. Module authors can be made aware of deprecations they haven't followed. POE needs more developers in a wide variety of areas. Short-term projects are available for people who have more skills than time. POE experience looks good on resumes. :) -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
