Releases: intel/parameter-framework
Version 3.0.0
The most significant change is the official support of Windows. Details follow. This version changes the Plugin API with 2.x.x versions hence the increase in major version number. Details follow.
In bold, the changes that are likely to have an impact for integrators of the Parameter Framework.
Major changes:
Windows support
- Compilation has been tested with Visual Studio 12 (2013) 64bits, using both the Visual Studio and the NMake build system generators provided by CMake.
- Run the legacy test suite on Windows. It was using UNIX-specific constructs but has been reworked to be portable.
Features
- Binary export of settings has been suppressed (We didn't know of anyone using it).
- Removed the "big endian subsystem" feature. We never heard of anyone using it and it wasn't correctly tested. We have added this feature in the long-term requirements documentation. The "BigEndian" XML attribute is now invalid with regard to XSD validation but the code will silently ignore it.
- Starting the remote interface no longer depends on the presence of the remote-processor library: it now solely depends on the "TuningAllowed" attribute in the toplevel configuration.
Plugins
The API provided to the plugins has changed in a non-retrocompatible way. Plugins need to be adapted. Look at changes in the skeleton-subsystem and the test-subsystem for reference.
- The plugin entry-point symbol name no longer depends on the name of the library file containing it. Instead, it is fixed and the same for everyone. The entry-point signature has changed.
- Also, this symbol name is provided as a C macro so that plugin developers don't have to worry about it being incorrect.
- This macro's name will change whenever the API is changed in a non-retrocompatible way, so that plugin developers will know at compile time that their plugin is broken.
- As a consequence to the API change, plugins can now log in their constructors and destructors.
Android integration
The Android.mk makefiles have been removed. They may come back later on a dedicated branch or be left as an exercise to the Android integrators. We have done this in order to avoid misalignments between build systems.
Under the hood
- Compile with C++11 and use some of its feature for both achieving better code quality and portability: C++11 provides support for threading.
- Use ASIO (standalone version, aka non-boost) for networking in the remote-processor library.
- Hide non-API symbols (using visibility attribute on GCC/Clang or declspec on Windows)
Minor changes:
Features:
- test-platform daemonization has been removed (because it was not easily achievable on Windows and can be achieved by the user on Linux)
- remote-process interactive mode has been removed (it wasn't used much and was relying on a poorly-written and non-portable tokenizer)
- Support for Floating Point parameters (obeying the IEEE 754 norm)
- API methods
{get,set}SchemaFolderLocation
are replaced with{get,set}SchemaUri
. As the name suggests, it takes a URI instead of a path but it is retro-compatible (under the hood, it uses functions provided by libxml2 which understands paths as URI). - A new parameter adaptation has been added: Logarithmic Adaptation
Build and CI
- Explicitly depend on CMake 2.8.12 or later (we are using features introduced in that release)
- We use "AppVeyor" as Windows CI engine.
Tests
- Test the skeleton-subsystem
Misc
- Write a "requirements" documentation: http://01org.github.io/parameter-framework/requirements/
- Lots of under-the-hood changes and reworks for portability.
- Fixes of defects found by static analysis tools.
Statistics
Since v2.6.1, 17 issues identified through static analysis were fixed (there used to be 22). Code coverage has improved from 71.42 to 74.11.
Known issues
The "Plugin" API needs rework. Since the plugins can theoretically access all of the data in the Parameter Framework, we need to export so many headers. On Android - because headers are usually not installed but rather "exported" (as a usage requirement, which is similar to how it is done intra-project with CMake) this can lead to a name conflict.
Version 3.0.0 RC3
This is a Release Candidate
New things since the RC2:
Major changes
- Removed the "big endian subsystem" feature. We never heard of anyone using it and it wasn't correctly tested. We have added this feature in the long-term requirements documentation.
- Run the legacy test suite on Windows. It was using UNIX-specific constructs but has been reworked to be portable.
Minor changes
- Compilation warning fixes
- CMake improvements
- Several code cleanups and fixes
Version 3.0.0 RC2
This is a Release Candidate.
The most significant change is the official support of Windows. Details follow. This version breaks the Plugin API with 2.x.x versions. Details follow.
In bold, the changes that are likely to have an impact for integrators of the Parameter Framework.
Major changes:
Windows support
- Compilation has been tested with Visual Studio 12 (2013) 64bits, using both the Visual Studio and the NMake build system generators provided by CMake.
Features
- Binary export of settings has been suppressed (We didn't know of anyone using it).
- Starting the remote interface no longer depends on the presence of the remote-processor library: it now solely depends on the "TuningAllowed" attribute in the toplevel configuration.
Plugins
The API provided to the plugins has changed in a non-retrocompatible way. Plugins need to be adapted. Look at changes in the skeleton-subsystem and the test-subsystem for reference.
- The plugin entry-point symbol name no longer depends on the name of the library file containing it. Instead, it is fixed and the same for everyone. The entry-point signature has changed.
- Also, this symbol name is provided as a C macro so that plugin developers don't have to worry about it being incorrect.
- This macro's name will change whenever the API is changed in a non-retrocompatible way, so that plugin developers will know at compile time that their plugin is broken.
- As a consequence to the API change, plugins can now log in their constructors.
Android integration
The Android.mk makefiles have been removed. They may come back later on a dedicated branch or be left as an exercise to the Android integrators. We have done this in order to avoid misalignments between build systems.
Under the hood
- Compile with C++11 and use some of its feature for both achieving better code quality and portability: C++11 provides support for threading.
- Use ASIO (standalone version, aka non-boost) for networking in the remote-processor library.
- Hide non-API symbols (using visibility attribute on GCC/Clang or declspec on Windows)
Minor changes:
Features:
- test-platform daemonization has been removed (because it was not easily achievable on Windows and can be achieved by the user on Linux)
- remote-process interactive mode has been removed (it wasn't used much and was relying on a poorly-written and non-portable tokenizer)
- Support for Floating Point parameters (obeying the IEEE 754 norm)
- API methods
{get,set}SchemaFolderLocation
are replaced with{get,set}SchemaUri
. As the name suggests, it takes a URI instead of a path but it is retro-compatible (under the hood, it uses functions provided by libxml2 which understands paths as URI). - A new parameter adaptation has been added: Logarithmic Adaptation (TODO: more details)
Build and CI
- Explicitly depend on CMake 2.8.12 or later (we are using features introduced in that release)
- We use "AppVeyor" as Windows CI engine.
Tests
- Test the skeleton-subsystem
Misc
- Write a "requirements" documentation: http://01org.github.io/parameter-framework/requirements/
- Lots of under-the-hood changes and reworks for portability.
- Fixes of defects found by static analysis tools.
Version 2.6.1
Major changes:
- Introduce the Client Simulator (see the README). This is a framework for integration tests. It has its own CMake project - if you want to install it, run the usual cmake/make invocations in tools/clientSimulator.
- Wrote a functional-tests plan and started to implement some of them. This new test suite uses the (native) client interface and will, at some point, replace the previous test suite which was using the remote interface.
Less important changes:
- Fixed an infinite loop during plugin loading. It happened when a plugin was not correctly presenting its entry point.
- Criteria: check for duplicate criterion literal values (only duplicate numerical values were checked so far); return an error to the client.
- Correctly forward libxml2 error messages to the client instead of dropping them.
Misc:
- Doxygen fixes
- Some dead code removal
- CI: Coverage fixes
Version 2.6.0
What changed:
- Support Darwin build in the Android build system.
Note: Native Darwin build fails (triggers warning treated as errors) and is not officially supported. - Minor format changes in the Doxygen documentation.
Plugin's Android build system is broken by this release as libxmlserializer is now a shared library on android.
For an example on how to fix your plugin, see the filesystem plugin fix
Version 2.5.0
Changes brought by this release:
- Two new remote commands:
exportDomainWithSettingsXML
andsetDomainWithSettingsXML
- Better libc call error handling
- Export the "Unit" and "Description" attributes in the output of
getSystemClassXML
- Fixes related to Python bindings: thread safety and force 32bits compilation on Android
- New
doc
make target for Doxygen generation
Version 2.4.4
Minor bugfix release
- Fix the xml coverage script
- Prioritize python 2.7 in CMake (travis was using python2.7 interpreter but python3.2 libs)
This release also contains changes to the travis config file to use their "container-based" infrastructure.
Version 2.4.3
Most significant changes:
- Portability
- Some windows-related fixes (windows is not supported yet but we are closing the gap)
- C bindings
- Tests
- Functional test suite
- Refactors related to CTest
make test
can now be run withoutmake install
- Continous Integration
- Integration with "coveralls", a coverage reporting tool: https://coveralls.io/r/01org/parameter-framework
- Make valgrind errors fatal for the CI
- Misc
- Fixed bash completion installation directory
- Some dead code removal
- Misc cleanup and fixes
Version 2.4.2
Most significant changes:
- Lots of improvements related to travis CI and CMake
- Have travis install more recent version of some tools
- Install the python bindings module and shared library to the OS' dist-packages location
- Some travis CI and CMake cleanups
- C bindings
- The parameter-framework can now be used from pure C code
- Android:
- Helper makefile for "EDD to XML" conversion
- Fixed point
- The tests never returned an error value even when failing
- Convert the tests to use the python bindings instead of remote-process (much faster)
- Fix some test cases
And three minor enhancements.
Version 2.4.1
Minor bugfix release:
Fix CSelectionCriterionType::getNumericalValue when called with an uninitialized argument.