Antwort: Nagios 3.0.7 release?

Andreas Ericsson ae at op5.se
Thu Jun 25 12:23:30 CEST 2009


Thorsten Tüllmann wrote:
> Hi,
> 
> Sascha.Runschke at gfkl.com wrote:
>> 3.2.0 is ante portas and will be the next stable release (soonish).
>> The 3.0 branch won't be developed any further as far as I know.
> 
> Soonish is kind of a bad word in relation to security. Ethan used to
> react on such issues quite fast by releasing minor updates.
> 
> I guess we all agree, that those "test fixes" in 3.1 need some time to
> grow stable. I would not even consider a 3.2.0 for our production
> environment on the day of its release.
> 
> The current problem is no big deal for our site, but there might be
> severe consequences for other installations.
> 
> IMHO it should really be considered to build a release management with
> ways to deal with needed out-of-order bugfix releases.
> 
> If solely the odd minor versions are developed and maintained the whole
> idea of a stable branch gets kind of useless.
> 

I'm not quite happy with the versioning scheme myself, but for another
reason; Module stability.

I'd like to see a versioning scheme that has "A.B.C.D" where:
D gets incremented for bugfixes only. No change in behaviour, output,
API's or ABI's. Performance improvements that do not alter any of the
aforementioned things can also be added here if the earlier performance
pattern is considered so bad it's actually buggy.
C gets incremented when there's a change in the ABI. Modules need to
be re-compiled against new Nagios headers when this happens.
B gets incremented when there's a change in the internal API's, so
that modules may need to be modified in order to run properly.
A gets updated after major re-designs. All bets are off when A gets
updated.


Fortunately, we're moving Nagios development to git right after the
3.2.0 release. Git is a lot better at branch-management and merging
than the CVS is, so a versioning scheme such as the one above will
be a lot easier to maintain. Some other changes I'd personally like
to see is that beta releases have their destined stable-release
number, but get the suffix "betaX", where X is an incrementing
number for each beta-release made prior to the stable release. Once
we enter beta state, we only accept bugfixes for that release. The
stable release will always be identical to the last beta, since
that's what people will be testing with.

We'll see how it pans out though, but expect a pretty quiet period
after 3.2.0 is out the door, since some infrastructure changes will
be done then.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------




More information about the Developers mailing list