Finally it is done, the 0.7.0 API is finished. The API covers everything shown in kdb.h and all releases in 0.7.0 will be 100% ABI and API compatible supported for at least a year.
Some bugs might break that rule, but there should not be left many anymore, because every method is at least checked twice and most have hundred of test cases. Please report any bugs you find to http://bugs.libelektra.org
This is not valid for kdb-tools, there are lots of bugs remaining there and a rewrite would be very useful.
For that reason there will be a separate release for kdb-tools, libelektratools and the backend interface.
The stable APIs of libelektratools and the backend interface will be announced separately, but they will be part of 0.7.x.
kdb-tool and kdbedit and so will also have separate releases, but because they are not a library there is no API or ABI issue there.
Pages related to 0.7.0:
Download it from:
The last release candidate before 0.7.0
I am proud to present the finished 0.7.0 external API in kdb.h.
A lot changed to 0.6.10 but the fundamentals are clearer then ever before: 3 Classes with their methods, a clear, easy and mature API. It is very hard to use it wrong but you get best results with very short code:
Other parts are not finished, like libelektratools, the kdb-tool and the backend interface. They are not part of the official 0.7 release and get their own release later.
The reasons to release within the next week are:
- The API is finished - Oyranos needs a stable release from elektra - the last release is long ago - unstable has been much more stable than stable since some time - there have been no commits to the stable branch since unstable existed - Elektra grows just too complex to wait for all parts to finish
Now some highlights from one month of work from 333 ChangeLog lines:
- many many bugs were fixed - the core completely compiles with -ansi -pedantic -std=c99 - all code compiles with -Wall -Werror - the test-suite is now complete - much cleaner infrastructure within the code - many autoconf/automake issues fixed - static, dynamic building, linking with defaults backends everything works! - many new options to stat and remove all keys and so on.. - environment variables and passwd database allow subtle influence of where the user configuration resides - kdb info now prints where configuration lies on hard disc
I am proud to present the fourth release candidate of elektra 0.7.0.
It is now possible to enable and disable Backends and Bindings with configure switches. The documentation was improved. The c++ binding now basically works, see the tests for examples. Ini and Berkleydb backends now compile again. There were a lot of bug fixes, like mntent.h fix for Mac OS X.
The new release candidate is available under: [1]
Unfortunately there is not much response about the 0.7 release candidates but there is still a lot to do to have a mature library worth to be announced as stable.
We would need help in many parts, see full Text in Call_for_0.7_finish.
The new release candidate is available under: [2]
The svn id is unstable@1352: [3]
We proudly present the second release candidate for Elektra 0.7.0. Many bugs were fixed, kdbGet() and kdbSet() are now really stable, useful and well documented. test_kdb also tests hosts and fstab next to filesys with 6598 test cases.
kdbSet() now supports a parent key to set only a part of the configuration passed by the keyset, allowing to e.g. save system and user configuration seperately. It only calls kdbSet_backend() when it is actually necessary. The splitting works much more efficient with n*b instead of n^2*b.
The highlevel functions kdbGetKey() and kdbSetKey() now work well with Capabilities. This allows very easy changing of keys inside backends even with some lacking capabilities, see GetStartedMounting.
Patrick Sabin and I wrote our bachelor thesis about mounting backends for configuration. It gives a detailed introduction in problem and choices and the actual implementation. elektra.pdf elektra.ps.gz
We proudly present the first release candidate for Elektra 0.7.0. Many large Changes were done. Elektra now supports multiple backends at once. That means every path like user/sw or system/filesystems can reside in a different backend. The Keyset was rewritten and much much more.
Despite of this there are only some API changes.
For the 0.7.0 release we won't make any API changes (neither to applications nor to backends), or incompatible ABI Changes, so please try to find all API/ABI related bugs there during the release candidates.
0.7.0 will be at least maintained for the year 2008, so you can consider using it in your applications. We also would like to see it in some distros included.
There is an updated TODO list for more information towards 0.7.0.
Get started mounting your backend now.
Thank you for all your work which made this possible. Markus Raab
There is some progress in unstable. See updated Roadmap for details of current changes. Homepage was updated in Backends, Bindings and Patches.
The simpler interface to Backends should be finished within next week, mounting backends should be finished within this month.
See TODO and Changelog in svn for unstable for latest information.
Elektra will be presented at Linuxwochen in Wien by Markus Raab.
The Migration of svn, homepage and bugdatabase is now complete, thanks to José Luis Tallón!
New features and redesigns will now hit the unstable branch. This will allow to use Elektra without being forced to do API changes in adverse times. See Roadmap for planned changes, major points will be:
You can Download the unstable branch with svn.
You can download source code & RPMS on sourceforge.
Thanks to reports bugs and problems to our bugtracker.
From Mingwang: "This project add libelektra support to SAMBA so that smb.conf can substitue with a elektra database which provides a registry-like parameter holder. And the storage backend behind it can be file system,berkeleydb,ini,etc.Legacy smb.conf can transfered to elektra database automaticly."
Have fun !
Samba.org, with Jerry Carter, expressed the need for a better way to do configurations, pointing Elektra as a substitute to smb.conf, and inviting developers to write patches for Samba (also known as elektrification of Samba) through Google's Summer of Code benefits.
From Samba.org:
Alternative configuration backends (Samba 3)
The current smb.conf does not allow the flexible set read and modify individual key/value pairs from within smbd. This project would explore using a registry like backend that would allow more flexibility is managing Samba's configuration settings outside on a simple text editor. The Elektra project provides a common configuration library with storage plugins. One possibility would be to implement an LDB backend along with a simple command line interpreter/editor.
A bug prevented elektrified Xorg to read display's modes. Up to date patch and RPMs is available on the sourceforge project page http://www.sourceforge.net/projects/elektra.
According to this request, SUSE/Novell recognizes the need to provide ISVs a better, more consistent, standarized and integratable way to deal with software parameters, and considering Elektra library and tools to be included in the SUSE Linux distribution.
If you think Elektra can help SUSE Linux to become a better, more integrated choice for ISVs and for users, let them know your opinion extending that request.
