====== Upgrading apps using OSInet FSM ======

The 2012 versions of the OSInet FSM are expected to be compatible with version 1.6 regarding machine descriptions ; however, the code has been refactored to the PSR-0 autoloading standard, and therefore requires PHP 5.3.
===== 1.4 to 1.6 =====

  * Files have been renamed at temporary version 1.5
    * Finite_State_Machine.php used to be u_fsm.php 
    * Background_Application.php is introduced: this is a new abstract base class for PHP-GTK applications using an FSM to perform background tasks.
    * fsm::* constants have been renamed to Finite_State_Machine:* constants.
  * Various changes to ZF coding style.
  * No significant feature change, but compatibility broken with the initial FTP downloader.

===== 1.3 to 1.4 =====

  * No application changes are necessary, BUT :
  * applications can now use external FSM descriptions in XML format. Building the FSM directly in code still works but it deprecated. It may go away at some later point. Constructors now typically look like just this:

<code php>
  function __construct()
    {
    $this->load_fsm();
    parent::__construct();
    }
</code>

  * The XML file holding the FSM description is found by default if it is called <foo>.xml for class <foo>. Otherwise, use load_fsm($url);

===== 1.2 to 1.3 ======

  * No application changes are necessary.
  * New features:
    * enable/disable idle processing 
    * idle() shorthand method
    * additional operation modes:
      * fsm::EVENT_NORMAL works as previously
      * fsm::EVENT_QUEUE queues events for later use
      * fsm::EVENT_SINK discards events
    * enable/disable post-event actions

===== 1.1 to 1.2 ======

  * The new post-event action feature allows shorter automata by event chaining
  * The new default "idle" event allows automatic progress in the absence of explicit events. For instance, whereas a FTP client using FSM 1.1 will typically send events to connect, get and disconnect in PHP, the same can be done to a large extend using just the transitions table with FSM 1.2 using this mechanism to fire events in succession.
  * Because of this change, fsm::apply_event() now returns a fsm_result instead of directly returning the next state. Code needing to know the next state can:
    * either use apply_simple_event, which is equivalent to the previous incarnation of apply_event
    * use the fsm_state field from the value returned by fsm::apply_event