Github user geomacy commented on the issue:
https://github.com/apache/brooklyn-server/pull/743
I've had a further think about the versions as discussed in
[#740](https://github.com/apache/brooklyn-server/pull/740#issuecomment-311631969).
In a (long) nutshell:
* I think we agree that there _could_ be problems with the approach here
_in edge cases_ where people are using version formats that we don't recommend;
in particular, as you note "one place this could be an issue is if we've relied
on OSGi to resolve version ranges."
Re. the latter I'm imagining a case like your 'acme-cluster' ([mail
link](http://mail-archives.apache.org/mod_mbox/brooklyn-dev/201706.mbox/%3C2c13060e-58d9-1098-ddd0-e713575b80e7%40cloudsoft.io%3E))
where someone has released a series of drafts, say, `acme:1.0.0-v1` , ..
`acme:1.0.0-v9` and `acme:1.0.0-v10`. Things started settling down around
`v5`, so if I have a bundle that depends on `acme`, and I specify an OSGI
dependency on it, I would like to be able to say
Import-Package: acme;version="[1.0.0.v5, 2)"
but I will have to understand that this will exclude `1.0.0.v10` when it
becomes available and write my poms/boms appropriately. That's probably
something you would expect me to understand if I am writing `Import-Package`
declarations and have read the new Brooklyn docs on versions. However it's
something we should bear in mind if we introduce version ranges in Brooklyn
catalogs, where if I write the following I think I should be entitled to expect
it to work with `v10`.
classpath://acme:[1.0.0-v5,2):/catalog.bom
* I guess I agree that this is too far below the radar to be a deal
breaker for this PR, and we can go with your
[suggestion](https://github.com/apache/brooklyn-server/pull/740#issuecomment-311903131)
of "a recommended syntax, and warn but make best effort if people not using it
-- is best for now, and we can become stricter in the next version."
* However, one final caveat, worth considering before merging: in your
updates to `Osgis.BundleFinder` you haven't changed the
[comparison](https://github.com/ahgittin/brooklyn-server/blob/e742da7bdf22ac41aaa68002f6b05058a65f8442/core/src/main/java/org/apache/brooklyn/util/core/osgi/Osgis.java#L215)
in `findAll` where the bundles are sorted in order to be able to return the
latest in `findOne`. In the `acme` example above this will mean `findOne` will
give you `v9` as the latest even when `v10` is out; I would argue that this
should return **Brooklyn's** notion of what is "latest", so we should be
re-mapping from OSGI bundle version to `BrooklynVersion` before doing the
comparison. Otherwise I think it really will give us problems where the wrong
bundle is picked.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
