We’re updating the Checkmk Exchange soon! This update will bring a fresh new look and improvements behind the scenes.
As part of this update, we’ll also be performing a major cleanup of the packages. Any package that only contains versions for Checkmk 1.6 or older (which are no longer supported) will be removed. This will help ensure that the Exchange only lists up-to-date and usable packages. The packages for 1.6 will also not be possible to upload.
If your package includes both older versions and newer ones (starting from Checkmk 2.0), it will remain available.
UPD: only the packages that have no contact information (moved from the old Exchange) will be removed during the first iteration. I will contact the authors of the rest to clarify their plans regarding the package.
If you have any questions, feel free to reach out or contact us at community@checkmk.com.
I am not sure if this is a good decision. Even the very old extensions contain information about a check’s logic. E.g. an SNMP extension contains OIDs queried and what to do with the data. If necessary another person would be able to use this information to implement the check plugin for modern Checkmk versions.
But yes, any improvement of the exchange is welcomed.
I agree, I believe that they should be kept until a newer candidate appear that can deliver the same functionality. A tag or category could be used for those old extensions.
Bitte alte Daten nicht löschen, wir als Kunden benötigen die Info’s, auch wenn sie alt sind. Die Daten sind ja von und für uns Kunden. Software hat kein Ablaufdatum und es ist nicht nachvollziehbar, warum nun wieder Informationen minimiert werden. Erst das “Feature Portal” und nun der Exchange Platz für und von Kunden Lösungen.
Please do not delete old data, we as customers need the information, even if it is old. After all, the data is from and for us customers. Software has no expiration date and it is incomprehensible why information is now being minimized again. First the “Feature Portal” and now the Exchange space for and from customer solutions.
1+ for an archive of contributions, many have never been on github or other public repositories. I mean at the very least drop a tarball on archive.org or offer another means of ‘download all’ for the hoarders.
either way, it would also be nice if you publish a list of what will go which way - in advance. that would be a great feedback and allow the community to consider if someone should chime in or just let it go to the final resting grounds.
Unfortunately, these packages that we are talking about cannot really provide any functionality at this point as they are completely incompatible with the APIs of the supported versions of Checkmk, as these packages are at least 5 years old.
But I hear you, we’ll try to figure something out and an archive sounds like a good idea.
Just my comment on the issue (also as a fellow developer of plugins):
As suggested above i opt for the creation of some sort of ‘Legacy’ exchange, and move them there.
Label that ‘Legacy’-exchange with the explicit reference that they are ‘Legacy’, and to get them to work (again) effort needs to be made to transition them to a/the current API (with link to the migration docs/videos/material).
Motivation:
The developers of those items have logic in there to check/monitor stuff.
If someone is looking for it, and invests the time to migrate them to current API-Standards they do not have to re-invent the wheel as to how to obtain the information for a/the plugin ( now reflected in libexec or server_side_calls).
I would consider it a total loss if those old packages were deleted as it would erase valuable information for any (future) developer who is looking for references.
It was decided that the old packages will be available on the exchange as an archived file.
That way, you would still be able to access them, if needed.
Another good news is – we expect the Exchange update to happen at the end of the week
I hope you really like the new look the Exchange is getting
If possible, i would like to see as an enhancement a distinguished counter in downloads per version of a/the available plugin.
Potentially create/see a combined count of all version-downloads.
Why: there is atm no insight in who is/has the latest version, just a total counter as to downloads.
To be more specific:
downloader downloads v1.0
counter for downloads is incremented to 1
maintainer adds version v1.1 (fixing/enhancing stuff from v1.0)
next downloader downloads ‘a’ version ( no details given as to which version he/she downloads), still the download -counter is incremented to 2
This gives (IMHO) a weird display of download-counts.
As updates/new versions of a packages are created/made with a reason every version (again IMHO) should have its own download-counter.
Just as an example:
I have added this for consideration after your last message – if I am not mistaken, it is the same counter
Thanks for describing in more detail what it should look like, it will help! I cannot make any promises but I will add it into the list of potential improvements.
or offer another means of ‘download all’ for the hoarders.
