@rlkoshak It doesn’t look like [5.2.0.0,) is working, because if it’s recognized as a valid range, it should be hidden when browsing from OH. I know that I suggested support for open-ended ranges a long time ago, but I’m not sure that it was actually accepted… honestly, I can’t remember.
edit: The problem with the version range might simply be that the , should be a ;.
It’s a bug in the logic that makes it necessary. I’ve refactored the whole thing in a branch I have, but since my marketplace work stranded, it’s still just sitting there. I guess I could extract just that part, but there seems to generally be very little interest among maintainers for anything related to the marketplace, so it’s hard to get any attention to PRs on the topic.
I agree that some better information would be helpful. It all goes to what appears to be a somewhat lukewarm interested for anything community marketplace.
Regarding the “bug” with the version parsing, even if we fixed it in a new version, the “old system” would have to be used for anything that should be understood by older versions… making the whole thing even more complicated, so it might be better to just stick to using 4 numbers.
Nah - this is a pattern that must be recognized as a whole, so you need something to make it stand out from other text - so some kind of brackets is probably required anyway. Why not make use of the already well established “meaning” of these different brackets? Anybody that use Maven will at the very least be well familiar with these.
That’s one of those twists that’s there just to confuse you. That setting isn’t under “community marketplace”, but under the general “add-on settings”:
TBH using [ and ( is esoteric. “Most” end users don’t understand it. Even if I’ve read it once, after 6 months of not dealing with it, I’d forget again and I’d have to look it up again.
I think it’s just fine. End users don’t need to understand it, only those that post on the community marketplace must, and there should be a clear, concise documentation for how to do that anyway. In any case, it’s too late to change this, since we can’t change how previous versions of OH interpret it. We’re bound to continue down the existing track.
But, I think [4.2;5.3) is much cleaner than (>= 4.2, < 5.3).
By the way, there are more “quirks” than you should believe in this system. In my refactoring I’ve dealt with all this. Basically, using [5.0.0;5.2.0) won’t work the way you think, because any 5.2.0 milestone or release candidate are considered to be “before” 5.2.0. I think there’s also an issue with snapshots, but don’t remember the details.
I changed this whole logic to what I considered to be “reasonable to humans”; that 5.2) actually only means versions prior to 5.2 in all its variants, not the release specifically.
I didn’t mean that you should turn it on. But, when it’s on, you should see two versions of that add-on. Please check if there are two add-ons with that name…
You definitely need to remove the old installed one before installing the new one. The old one show disappear and the new one appear at the end of the list. At heart that’s been my experience. On rare occasions I need to restart OH to see the new one, but that may be a side effect of all the other stuff I’m doing at the same time.
It seems to be half working. It does show up in 5.2 when I have the market place settings to only show published entries. But it is still showing the version number. I’ll try the semicolon instead of comma.
When I get to a computer I will. Normally I don’t really care but for a market place entry it makes it harder to support users of the template.
Not everyone who does so will be much more than users. Especially now that creating templates has become a lot easier with the yaml file format.
I have to look up the maven versioning docs every time I want to do something different. In the end I usually just copy something and . And I still get it wrong.
@ErikDB, one little warning. Because I’m starting over for 5.2 I decided to standardize by logger names and template uids. So the usual regenerate path won’t work.
However, you can click the code tab of your rule and change the ruleTemplate to match the new ID, ohrt-presenceSim in this case. Then you can regenerate. I plan on worrying this up when I’m done with my last two templates.
. And I still get it wrong.
