[Xymon] Xymon version 5

[J.C. Cleaver]

On Sun, November 1, 2015 11:15 am, Henrik Størner wrote:
> Hi,
>
> J.C. Cleaver:
>> Xymon 5 is the trunk update Henrik has been working on for a while now.
>> The biggest core features are compression, sqlite as a data store, IPv6
>> and direct SSL communication support throughout, a new poller
>> (xymonnet2)
>> and page generator, and more streamlined client->RRD processing.
>> Development on it's been somewhat stalled with Henrik being busy at his
>> new position, but it's still definitely "on the roadmap". For a more
>> specific ETA on it, I'd have to defer to him.
>
> First, I must say that I am pretty impressed (and happy) with the way JC
> has managed the v4 codebase. I think I made the right choice when I
> handed it over to him.

Thank you :) It's been an honor to help out with such a useful project.

>
> Re. version 5 ... well, most of the code is there. One of the last
> releases I did was an alfa/beta/preview/whatever with the new networking
> code. But it does need some cleanup, and re-adapting into the current v4
> code - it was originally branched off 4.3.7 I think, and since JC took
> over I haven't fitted any of his fixes and enhancements into v5-code.
>
> And unfortunately I don't have the time to do any serious work on it.
> Version 5 just turned out to include too many changes and enhancements,
> it should never have gone for so long without a release.
>
> I think the best way forward is to slice the version-5 code into smaller
> pieces, and then gently slip them into the current v4 code. There are
> some generic changes that could easily move back into v4, and then some
> more serious changes for the new networking code. But even that could (I
> think) me nudged into the v4 code, and live alongside the current
> net-tool. That would probably be a slightly less intimidating set of
> changes.
>
>
> Regards,
> Henrik
>

I think this would work out really well... Migrating library functions
together would help ease the transition over to the new code, which could
be done in gradually and in parallel. With core support, the various
worker modules and daemons could be brought to parity as testing permits.

Having a good version-specific baseline to compare the trunk to really
helps, too. It'll make the commit-analyzing and diff-wrangling a lot
easier.

The more I think about it, the more I also like Adam's idea of assigning
point release versions to various functional milestones. We can focus on
the core compatibility and flesh out the component support one block at a
time.


Regards,
-jc