Andreas Ericsson wrote:
>
> 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.
>
this sounds good to me.
>
> 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.
>
I'm looking forward to this, the beta state is like a freeze period for
me, in which only testing and bug fixes go in. once this is in place, I
would be a lot more confident about upgrading to a new release knowing
it was tested for some time.
thanks for this mail.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]