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