# New for 1.2

# Highlights

With the release of Sedona Framework 1.2 a number of features have been added.

- Versioning: You didn't miss anything, the Sedona open source version skipped from 1.0 straight to 1.2.
- Kit and Platform Manifest Server: Kit and platform manifest files can now be stored directly on the Sedona device, if desired, and served automatically to Sox clients as needed. See the section Manifest Server to learn how to implement it on your platform.
- Device Discovery: Sedona devices can now be discovered automatically using IP multicast. Details can be found in the section on Device Discovery.
- Multi-rate App Components: Components now have some control over when the App cycle executes their child components. This can be used, for example, to have certain child components execute at a lower rate than the App cycle rate. See the Apps chapter for more details.
- Device Simulation: New capability has been added to `sedonac` to make it easy to create a simulator version of any Sedona VM. Apps that depend on kits with platform-specific native methods can now be run on a different host platform using a simulator SVM. Detailed instructions on how to create a simulator SVM will be presented in the Sedona Device Simulator chapter.
- Refactored Control Kit: The `control` kit has been split into several smaller kits, organized roughly by functionality. This should make it easier to use the control components on resource-limited devices.
- Prioritized Array Components:
  A new kit `pricomp` offers components with prioritized inputs, including override capability:
  Each component in the `pricomp` kit uses a 16-level priority scheme, with inputs `in1` (highest) through `in16` (lowest) plus a `fallback` property, and a single output `out`. It also has override actions that explicitly set certain input slots.
  The value of `out` is determined by a priority scan of the inputs, looking for a valid value at `in1` first, then each of the other inputs in turn, all the way down to `in16` and then `fallback`. (A "valid" value is one that is not set to `null`, or its equivalent for that property's type.) The highest priority valid input propagates to the `out` slot.
  Most of the component inputs are linkable, with the few exceptions being inputs that can be set only via right-click override actions. Overridden inputs are evaluated along with the linkable ones, using the same priority scheme. `PrioritizedBoolean` components also offer built-in timers for minimum on and/or off times to protect sensitive equipment.
  See the pricomp kit docs for more about these components.