A good friend of mine, Minhchau Dang, pointed out to me that I have frequently used OSGi version ranges in my blogs.
I explained that I was concerned that I didn't want to bind to a specific version, I often wanted my code to work over a range of versions so I wouldn't have to go back and update my code.
He pointed me at the specifications, https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#i3189032, which indicate that I didn't understand that a standalone version also work as a range. Yes this link is for the 7.0 specs and we're not at 7.0, but the 6.0 and 5.0 specs echo the same thing, I just didn't have a working link to that section.
So, in case you don't want to spin out to the specs document, I'll summarize here...
You can specify a range like version="[1.2.3,2)" to supply a fixed range, or 1.2.3 <= x < 2. This range specifies both the lower and upper bounds and allows you to be inclusive or exclusive of values.
But, if you simply use version="1.2.3", you are also using an unlimited range, or 1.2.3 <= x. This range only specifies the minimum version, anything greater is just fine.
Well, technically, that is. As far as OSGi is concerned, if 4.0.0 is available, it will happily mark the dependency as satisfied. You have to keep in mind, though, that there is never a guarantee of backwards compatibility on higher version numbers. So while OSGi will resolve the dependency with 4.0.0, it may not at all be compatible with what you need as a dependency. You are likely going to be okay if 1.3.4 is deployed, or 1.6.7, but you will likely encounter failure with version 2.0.0. So keep in mind that ranges, although not necessary, will help to constrain your module to platforms that will actually successfully host your module.
Now, I suppose we can still have a discussion of what to do with respect to Liferay releases. I mean, I don't know how Liferay will version portal-kernel for the upcoming 7.1 release, but let's consider the following...
Normally the Liferay tooling will start you with portal-kernel version 2.0.6 which we now know means 2.0.6 <= x, so any higher number is fine. But it actually likely will not be for 7.1. We might actually need to use a version range like [2.0.6,2.1) if 7.1 uses a minor version bump or [2.0.6,3) if 7.1 does a major version bump and our code doesn't work on 7.1.
I guess we'll cross that bridge when we get there...