@r.sander : I disagree; for various reasons:
The most important thing of this change for us (backend maintainers, QA, developers) is that we have a unique name and an increasing version number for all packages. If I get presented with Package “Bar Extender 2.3.7”, I must be able to decide what its predecessor (on the Exchange) is. If I can have a situation where “2.0.12” is newer than “2.1.4”, that gets difficult.
Also there are packages that are compatible with more than one Checkmk version (I just saw one that claims to be compatible from 1.2.8 onwards!).
Also this would be one thing more to explain, one thing more “out of the ordinary”.
Lastly, a bit more theoretical, but important nevertheless I think: This would undermine the concept of semantic versioning. As the name suggests, it is not only a format spec for versions, but also gives a particular meaning to the elements of such a version (major, minor and patch version, prerelease version and build metadata). It is not only about having an order of the different versions, but also describing in what way the package changed.
I realize that one might have to maintain two “flavours” (I’m avoiding the word ‘version’ here…) of the same package, one for Checkmk 2.0 and one for 2.1. I’d suggest including this in the package name, as was done for python packages while python2 and python3 where maintained.
I know this might sound a bit pedantic, but I really believe that a major strength of this approach is following “Semantic Versioning 2.0.0” by the book.