I think maven is a case in point proving what happens when you do not
standardize versions. In maven 0, 0.0, 0.0.0, 00.00.0 are all different
versions, in OSGi they are the same (as they should be). In maven a version is
more or less string that gets mapped to a file name.
A version is a message to the future, the author promises to deliver new
revisions and the version of these future artifacts is promised to signal
compatibility with the existing revisions. Not standardizing version syntax is
like all of speaking different languages ...
oops.
Kind regards,
Peter kriens
On 13 sep. 2012, at 14:45, 向雅 wrote:
> 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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
