[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dash-dev] Version ranges or exact versions
|
This was mentioned in a different thread but I wanted to get the discussion going on this point specifically. (Cc'ing Jason in case he has thoughts on this too.)
The dependency problem is this: do we copy the ranges expressed by the manifest into Maven, or do we replace it with an explicit version:
<version>[3.2,4.0)</version>
<version>3.2.1</version>
The former, while valid, tends to be used less frequently. In addition, it will resolve (by looking at the maven metadata) at the *latest* build which may not be what we want.
Consider compiling against JDT UI, which needs JDT Core, for Ganymede. We would have in our code:
<dep><art>JDT.UI</dep><ver>3.5</ver></dep>
JDT UI would have:
<dep><art>JDT.Core</art><ver>[3.5,4.0)</ver></dep>
This would consult the latest, find Helios' release, and download JDT.Core 3.6.
So now we have JDT UI from Ganymede and JDT Core from Helios. This is not only an untested combination but there may be internal dependencies which don't follow the rule of compatibility, especially since these combinations aren't put to the test.
One can argue that range should be tighter but you could eg argue for the 3.6.1 vs 3.6.2 dependency as well.
Finally, version ranges demonstrate the fact you don't get repeated builds since what you build against is dependent on what the state the repository is in. This doesn't matter if you always want the latest and greatest because they are equivalent; but we have cases where people want to build against previous versions (especially when building +1) for compatibility reasons.
If we do go down the version range route we may want to have separate repo for each major release (eg /releases/helios and /releases/ganymede) so that when using a range you can restrict yourself to just that set. I don't believe this will be necessary if we are recording individual values in dependencies.
Finally, a hybrid approach might be to record the ranges in the poms and provide a dependencyManagement set which records explicit versions for Helios releases. Could we export this in some easy to consume way like having a pom.xml for Helios as a whole?
Alex
Sent from my iPhone 4
