Hi Nicola,

It seems we all agree on at least one point: it would be great to drop support for old libraries that are no longer available or are deprecated.

As for renaming or creating a branch, I do not really mind - both are fine with me. My only concern is that it should not (or only minimally) disrupt the work of rebasing 4.4 on top of the latest 4.3.x baseline, since the scope already feels quite large. Because of that, I am not sure what the best versioning move would be (keep 4.4, jump to 4.5, or go to 5.x). Going to 5.x could be a nice milestone number to mark a significant step forward.

Also, during my testing I noticed that we still have build practices that create a hard-to-follow matrix of possibilities. This was also a major pain point for me.

Finally, we already have a lot of material ready. It would be great if we could start using it without waiting for a full alignment of all branches.

Bruno

Le 02.03.2026 à 19:33, Nicola a écrit :
I think 5.x should have some features rather than just dropping compatibility: that's why I suggested 4.4.
Probably IPv6 support and all the changes which are in 4.4alpha could deserve a major version change

Just imagine the changelog for 5.x... ;) 

Jokes apart, I would commit to a 5.x if the quorum goes there: no problem at all (it's just "esthetic" after all)

Nicola



Il giorno lun 2 mar 2026 alle ore 16:28 IO Support <support@ionetworkadmin.com> ha scritto:
I also agree with a 5.x release.  Forward looking to the latest OS
versions and current security protocols is what needs focused on. If
someone wishes to use an older OS, then the older Xymon version will
work for them.  Backwards compatibility should not be the priority with
this forward facing effort.

Kris Springer
I/O Network Administration


On 3/2/26 9:16 AM, Stef Coene wrote:
> Hi,
>
> I too don't mind dropping support for old distributions but I prefer
> doing this while switching to a 5.x release.
>
> I think most of the old libraries are used on the xymon server and I
> don't see any valid reason to not upgrade the OS to a supported version.
>
> Worst case scenario (like I had when switching from 32-bit to 64-bit)
> you have to export and import the rrd files if you want to keep the
> history graphs.
>
>
> Stef
>
> On 2026-03-01 22:47, Nicola wrote:
>> Hi, I have been thinking about this in a while, and I am now
>> convinced that we should aim at a 4.4.0 release which just drops
>> support for old libraries not available or deprecated in modern
>> OSs/distributions.
>> We can rename and `sed` the version for the current 4.4 branch, but
>> this will ease many of the efforts which are draining our energies to
>> keep compatibility, and at the same time if we need minor bugfixes in
>> the 4.3 branch, we can add them for dinosaurs which still require old
>> libraries.
>> What do you think?
>>
>>
>> Nicola
>> Mastodon <https://joinmastodon.org/>: @nic@mathstodon.xyz
>> <mailto:nic@mathstodon.xyz>
>>
>> _______________________________________________
>> Xymon mailing list -- xymon@xymon.com
>> To unsubscribe send an email to xymon-leave@xymon.com
>
> _______________________________________________
> Xymon mailing list -- xymon@xymon.com
> To unsubscribe send an email to xymon-leave@xymon.com

_______________________________________________
Xymon mailing list -- xymon@xymon.com
To unsubscribe send an email to xymon-leave@xymon.com

_______________________________________________
Xymon mailing list -- xymon@xymon.com
To unsubscribe send an email to xymon-leave@xymon.com