Almost half a year after we started this project we can now announce the first release.
The version 0.8.0 is a stable release, which means it does not contain any known critical issues. It’s not a 1.x release yet because we felt like it’s a good idea to be able to change APIs before a final 1.x release. That said, the 0.8.0 is probably lot more stable than its predecessor.
We tried to make getting started as easy and convenient as possible, so there are binary downloads for common linux systems and source rpms available. Unless you have good reasons, you really should go for the binary releases - they are build to just work.
We spend a lot of time to build tests and fix the most critical bugs of Nagios 4. There is a list of active issues in the developers section. It’s not yet completed and we have to walk through all issues and decide whether Naemon is affected or not.
Naemon is a community project. So if you like this project, talk about it - or even better, help make it better. See the community page on how you can help.
Today we started the documentation project and you are welcome to help out. There is lot of stuff to write and the more people help, the less documentation has to be written by single person.
The issues with our build system have been sorted out and it seems quite stable and we only have to tweak some last things, like better init scripts, before we finally release the first version of Naemon.
We’re still working on getting a release out - unfortunately, we’ve been having some issues with our build system.
But we do have a new webpage - how about that?
One of our frustrations with Nagios is that while it does have a lot of tests, very few of them actually pass. That’s OK, though, because they’re executed very rarely.
Our plans for the future involve quite a bit of rewriting things behind the scenes, without any of our users noticing it. This is absolutely impossible to do without a much more serious QA effort.
Every night, the awesome Consol build cluster creates nightly packages for our primary platforms, and runs tests on them. There are currently 13 different OSes with two arches each, adding up to 26 different builds. As they also build binary packages, this makes it easy for others to do further testing. The whole process takes hours
But hours every night isn’t acceptable. We also need a modern CI system, with near-instant feedback on changes, which we have, thanks to travis. Several different core suites, as well as a few overall suites, are run per commit. This notifies us as soon as a test breaks and keeps quality and testing at the top of our minds.
While we have a lot of untested code today, going forward, there’s no reason for you not to include tests in your pull requests.