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
On 3/1/26 3:47 PM, 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.
Hum.
We can rename and
sedthe 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.
I don't object to a significant change in backwards compatibility in concept.
What do you think? I think that any such significant change in backwards compatibility should likely be done at a major version number. So how about 5.x instead of 4.4.x
Just my opinion.
-- Grant. . . .
I agree that dropping server support for older OSes is a separate issue to dropping client support, and this can enable a strategy to streamline progress on the server while maintaining backwards compatibility on aging hosts - some of us don't have the ability to promptly upgrade client hosts, and many people choose Xymon because of financial constraints that also apply to the personnel costs of upgrading. For now there are no suggestions to change the BB protocol that clients use to communicate with the server, and this "API" separation allows for a different support "policy" for the Xymon client packages and codebases.
However, there still may be difficult choices to make. If we don't want to cut off support for older OSes on the client, then the client packages still need to be published somewhere. Which means, if there's a new security vulnerability, those packages would need to be updated, which requires that the build environment needs to maintain support for old OSes.
J
On Fri, 6 Mar 2026 at 03:32, Scot Kreienkamp <Scot.Kreienkamp@la-z-boy.com> wrote:
I still have older versions in my environment. As long as the older clients are still able to send reports to servers running on the newer versions/OS's I don’t see any problems dropping support for the older OS versions. There's no breaking change here, we're just not releasing new software versions for older OS's. Along the same line, I don't think it would be a problem to use 4.4 as long as the older clients are able to send reports to the server on newer versions.
*Scot Kreienkamp | Applications Infrastructure Architect | La-Z-Boy Corporate * (734) 384-6403 | 1-734-915-1444 | Scot.Kreienkamp@la-z-boy.com One La-Z-Boy Drive | Monroe, Michigan 48162 | la-z-boy.com <http://www.la-z-boy.com/> facebook.com/lazboy | instagram.com/lazboy | youtube.com/lazboy
[image: LaZboy Logo]
-----Original Message----- From: Grant Taylor via Xymon <xymon@xymon.com> Sent: Sunday, March 1, 2026 5:30 PM To: xymon@xymon.com Cc: Grant Taylor <gtaylor@tnetconsulting.net> Subject: [Xymon] Re: Struggle supporting new OSs
On 3/1/26 3:47 PM, 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.
Hum.
We can rename and
sedthe 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.I don't object to a significant change in backwards compatibility in concept.
What do you think? I think that any such significant change in backwards compatibility should likely be done at a major version number. So how about 5.x instead of 4.4.x
Just my opinion.
-- Grant. . . .
This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
On 3/5/26 5:40 PM, Jeremy Laidman wrote:
However, there still may be difficult choices to make. If we don't want to cut off support for older OSes on the client, then the client packages still need to be published somewhere. Which means, if there's a new security vulnerability, those packages would need to be updated, which requires that the build environment needs to maintain support for old OSes.
I feel like Sendmail's idea of a "contributed code" section might be an option. As in -- if authorized -- Xymon can re-distribute code provided by contributors "as is". Meaning here's something you might find useful, but support of it is on you the end user.
Seeing as how there are really two components to the client; binary and scripts, I see little reason that the scripts can't be distributed. I'm quite successfully using the scripts on an ancient AIX 5.3 box with a custom Perl wrapper to send the output from the scripts to the Xymon server. (I don't have access to compilers on AIX to be able to compile the client binaries.)
-- Grant. . . . unix || die
Personally, I'm just a happy user of Xymon. So take my statement for what it is. However, if an OS no longer gets security updates, I make a point of getting it out of my environment. For example, Windows Server older than 2016 and FreeBSD older than 13.5 (the current "Legacy" release, which is the oldest that still gets security updates) have no place in any serious environment, IMNSHO.
If you wanted to offer a 6-12 month grace period, that's being realistic (or generous, depending on your perspective) about people migrating off of old systems. So maybe FreeBSD 13.0 instead of 13.5? Support for Debian 12 (EOL in June) but not 11 (EOL in 2024)?
Just my opinion. I'm not a good enough coder to contribute, but I thought my perspective might be a little bit useful.
Jaime Kikpole
Director of Technology Ichabod Crane Central School District (518) 758-7575, x5425
On Sun, Mar 1, 2026, 4:47 PM Nicola <canne74@gmail.com> 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
sedthe 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
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
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
sedthe 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
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
sedthe 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
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
Nicola Mastodon <https://joinmastodon.org/>: @nic@mathstodon.xyz
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
sedthe 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
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
Nicola Mastodon <https://joinmastodon.org/>: @nic@mathstodon.xyz
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 toxymon-leave@xymon.com
participants (8)
-
Bruno Manzoni
-
Grant Taylor
-
IO Support
-
Jaime Kikpole
-
Jeremy Laidman
-
Nicola
-
Scot Kreienkamp
-
Stef Coene