Well I royally messed that up. The first post ended up as post 20. 
I tried that on the Presense Simulation post and it still shows the version. But I also tried [5.2.0.0,5.9.9.9] at one point and it still showed the version numbering. But I didn’t go back to figure out why. Maybe the semicolon was needed.
Show potentially incompatable is turned off and show unpublished is turned off in my settings.
It shows up because it’s considered to not have a version range ⇒ show in all versions.
I didn’t mean that those posting to the marketplace should know it by heart, but that there should be a pinned post/documentation where it was all spelled out briefly (perhaps with a more in-depth explanation beneath), that people could use as a reference.
I’m pretty sure that would be needed regardless what the syntax was, most of us aren’t “used to” specifying version ranges.
And I managed to post in the other thread in the meanwhile 
It is the semicolon, I think I made comma supported as an alternative in my refactoring work, but since that only exists in my branch, it doesn’t matter. Only semicolon is supported.
Already moved it.
There is a thread somewhere where this was once explained to me at some point. I’ve long since lost it and will have to search it up again. It’s not the full Maven syntax as I understand it. More inspired by it.
Yeah, it doesn’t support the full Maven syntax because the implementation is somewhat “lazy”. But, I have already refactored all this a long time ago, so I’m currently trying to extract just that part from my old marketplace branch. But, whatever we do, there’s no getting around the fact that we’re bound by what older OH versions understand, so there isn’t a lot of freedom to change things here.
But, I’ve at least changed what I considered “bugs”, and if I manage to extract it and get it merged, perhaps it can become slightly better in the future. In “my version”, you can specify as few numbers as you want, so you could do e.g [5.2;6).
I could write the documentation/explanation for the versioning range part, since I know the code relatively well. But, I was thinking that there should be some document explaining “the whole process”, where to place inline resources, links, that you must use “raw” GitHub links etc.
The marketpalce probably deserves a separate page in the docs.
Using [5.2.0.0;) doesnt’ appear to work. But using [5.2.0.0;5.9.9.9] does appear to work.
Yes, I don’t think my suggestion for open-ended ranges was ever accepted either.
That form is actually better anyway, because it avoids the whole mess with pre-release versions. If you use [5.2.0.0:6.0.0.0), it will be available in 6.0.0 milestones and release candidates, but I’m not sure if it will in snapshots 
That worked! (The property was just template, apparently…)
The property names are all documented here: YAML Rules | openHAB
Is the marketplace source just hard coded to the forum id inside openhab?
If we were to come up with a better scheme (versioning number, syntax etc), we could create a “New Marketplace” e.g. for openhab 5.3+ and archive the old one. Openhab 5.3+ can load from both the new marketplace (and the old marketplace if that’s beneficial for the transition), whereas the older openhab versions don’t even know about the new marketplace. IMO there’s no need to stick to a bad system forever.
Yes, but I don’t see any reason to do anything like that. I’ve long wanted to move the “database” away from the forum, so that there’s a “proxy” running on a server that queries the forum regularly and then serves the OH clients. But, I’ve had no luck getting anybody to “help me” figure out how that would have to look. I don’t know the infrastructure, and what would and wouldn’t work.
But, to make a “break” is unnecessary - new clients can point to the new address, while old clients keep fetching directly from the forum. As older clients get fewer, the load on the forum subsides. It would be very bad to break the marketplace for older versions. I run 4.2.3 myself, I wouldn’t bother to host add-ons on the marketplace if I couldn’t use them. The whole point of all this, is to not break everything for those that doesn’t run the latest version.
I don’t see any point in making this “break” because you think that the version range is “bad” though. I think it’s fine as it is, only a bit bugged. But, there are many other shortcomings, so I have “made” another system that allows specifying more information.
If you look at this add-on, it’s the one I’ve used when developing support for versioning:
It allows specifying multiple versions of the same add-on, specify that an add-on depends on other add-ons, specify informration that you can’t today (documentation, issue tracker etc) - all this without breaking compatibility with the existing format.
This already works with the branch I’ve developed it against, as can be seen here:
There’s already support for third party marketplaces. I’m not sure how it’s implemented and whether it faces the same problems or even if it’s suitable. But it’s worth looking at.
You’re probably referring to the JSON source.
It’s largely the same code, the forum parsing stuff is separate for the community marketplace obviously, but the rest of the code is mostly shared. But, there are some inconsistencies there too, the JSON marketplace has another type of designation of “stable”/“unstable” than what the community marketplace has
I’ve extracted the version changes I made back then, and created a PR. If this is merged, it will fix many of the issues discussed here, at least for future OH versions:
