Hi all,
Digging into the version problem:)
Agree with DBC, but package not equals to contract, nor do module! In
practice, both is hard to forced for so many reasons.
IMO, the Version class is source of evil or argument. It's contrary to
the DBC fact!
And in comment of Peter versions blog, someone prefer Roman Numerals.
Yes it should be acceptable.
And maybe even Pi as 3.14, maybe I would pick TianGan & DiZhi "甲乙丙丁" "子丑寅卯".
As China saying, All tastes difficult to cater! Because 100 people
have 100 tastes.
And 4 segments style version format, hard to follow.The famous case,
JDK from 1.4 to 5.
Idea?
Yes, Locale!
Interface the version, even it can ignored! because it's virtual,
every source version is just string.
The key is VersionRange interface.
The "locale VersionRange" know how to validate the constraint of its version.
Because the module(bundle or package) only need know if it's compatible!
So seems like this:
interface VersionRange{
/**Just check out specified version if compatible the requirement*/
boolean compatible(String or Version);
/**If there are multiple candidates, return a elect*/
int priority(String or Version);
}
Then make the version package standalone as host, like DS, so fragment
from implementer or developer team be attachment.
Any thoughts?
致敬
向雅
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
