Now again the old problem with the exchange and the not available possibility to provide packages for different CMK versions.
At the moment i have packages with different content for 2.0, 2.1 and 2.2.
All need the same name that it is possible to update these packages without any problem.
Version numbers following the new guidelines.
2.0 package is starting with 2.0.1, 2.0.2 and so on
2.1 package 2.1.1, 2.1.2 …
Now i uploaded the actual 2.2 version and cannot update the older 2.1 package anymore. That is simply stupid.
With the suggestions from @moritz i cannot work - as it is nearly impossible than to keep all packages at the same “patch level”.
Conclusion at the momen → Exchange is broken or only usable for not updated obsolete old packages.
Everyone needs to keep in mind - if you build a mkp correctly for 2.2 it will not work with 2.1 and vice versa.
I recognize that this is a problem. Give me some time to look in to it a bit deeper. Hopefully we can come up with a workable solution for both the package creators and the devs reviewing them.
It is also a problem for the user who want to download a package. Without the possibility to select the used CMK version it is only trial and error to find the right package version.
Everyone needs to keep in mind - if you build a mkp correctly for 2.2 it will not work with 2.1 and vice versa.
This is unfortunate in it self, but that is exactly the reason why they should not be the same MKP just with different versions.
Why do the packages have to have the same name? Can you name them “FooBar for 2.1”, “FooBar for 2.2” and so on, without trying to encode the Checkmk version into the MKP version? This is the common way to go about this (for example urllib for python3 and urllib2 for python2).
Encoding the Checkmk version in to the MKPs version will never work, as it defeats the purpose of an increasing version number. And it is not correct in your case: 2.1.1 is not just a newer version of “the same thing” as 2.0.1.
I can get that you somehow want to mark those MKPs as “belonging together”. Would it help if you could in someway bundle your MKPs on the exchange?
With this you cannot update the packages. You need to remove and reinstall. This cannot be handled in bigger environments with 30-40 mkps installed.
The package name must stay the same.
Inside the Exchange there are two features missing. Selection of used CMK version and some type of real description where it is possible to write something about the packages, versions and limitations.
With this you cannot update the packages. You need to remove and reinstall. This cannot be handled in bigger environments with 30-40 mkps installed.
The package name must stay the same.
EDIT: You’re right Andreas, the following is wrong.
Hm. I see. With a distributed setup running different Checkmk versions you must have both MKPs installed in parallel, such that each remote site can run the right one. In that case the MKPs must not have the same name.
This would only help if the Exchange has a feature to select the CMK version and then present the same package (same version) for the selected CMK version.
But then you need a feature at upload time to specify the CMK version the package is for. Or the Exchange need to look inside the package for the minimum and maximum version setting.
The exchange is looking into the package anyway. I’m surprised it does not show the description, now that you mention it. Everything that is important to know should be in the manifest (a.k.a info file).
The exchange only uses the description and URL from the first uploaded version of the package. It does not update any of them from newer packages. I am missing the possibility to change the URL for my package.
That seems to be a bug to me. I was wondering why you hadn’t already fixed the dead link. @baris.leenders can that be fixed? Showing an outdated description is not ok, IMHO (but is slightly off topic here).
Thinking about this, I somehow have the feeling that there’s something that I do not fully understand about your use case. Can we have a (remote) chat about this?
Our requirement is that any MKP has a unique name, and is ordered by its version number from older to newer – it cannot be that difficult, can it?!
Anyway, I just realized: Fully embracing the semantic versioning would mean that you can for instance upload a 2.0.3 after you uploaded a 2.1.0; as long as an older 2.0 version is uploaded.
Maybe as a mitigation we need to drop that upload barrier. That would solve your problem, correct?
Just for the record: I just learned that every description is shown on the “All versions” tab. The package overview just keeps showing the oldest one. We have to pick one of them, but I think it rather should be the newest one (in terms of MKP version number, not upload).
We have discussed it a bit internally.
In the next days we are dropping the requirement for increasing version numbers. The version field will still be validated against semantic versions rules, but they no longer need to be increasing.
Also, in the next 1-2 weeks we will start updating the description, name and website of the package with the ones of the latest approved version.
There is no more need for increasing version numbers when uploading now versions of the MKP.
Whenever a new version/mkp is reviewed and accepted the package title, description and website of the package are updated with the information found in the MKP. This is only the case if the version has a higher version number than last.
