Hi all,
I noticed that product publishing always sets requirements for a fixed version of the contained bundles/features, i.e. the defined range has its lower and upper boundaries equal like this:
<required namespace="org.eclipse.equinox.p2.iu" name="TestBundle"
range="[1.0.0.201009171510,1.0.0.201009171510]" />
while I need something like this:
<required namespace="org.eclipse.equinox.p2.iu" name="TestBundle"
range="[1.0.0.201009171510,2.0.0)" />
or even this:
<required namespace="org.eclipse.equinox.p2.iu" name="TestBundle"
range="1.0.0.201009171510" /> (which means “any version > 1.0.0.201009171510”)
The .product file format does not support a way to specify a range for its components, only an attribute for a fixed version. The product publisher also has no notion how to generate version ranges – it simply sets the range boundaries equal to the component
version (see method AbstractPublisherAction.createIURequirements() for reference). So far, I cannot find a way how to workaround this issue and in my opinion it as a limitation of the product definition concept.
Why is this so important ? The use case is like this:
I am developing a product consisting of several components which is getting published on an update site on a regular basis. The components receive frequent updates in the p2 repository and their versions are incremented which is reflected in the requirements
of the published product. However, once I install this product, I cannot apply updates to the system any more. The updates are refused because version ranges of the requirements for the installed and the updated products do not intersect which seems to make
them incompatible.
This wouldn’t be the case if it was possible to define open ranges in the product file. For example, the installed product would require a specific component in version range [1.0.0, 2.0.0) while its new version would require it in the range [1.1.0, 2.0.0).
This would allow the update to pass because obviously range [1.1.0, 2.0.0) is compatible with (falls into) range [1.0.0, 2.0.0). The way they are generated now is [1.0.0, 1.0.0] for the old product and [1.1.0,1.1.0] for the new one. Since these two ranges do
not intersect, the update is not possible.
In short, I have two issues and hope to receive some advice from you how to address them:
- Is it possible to define a product with extended version ranges of its components ?
- What makes product versions compatible for update ? Why changed version requirements, which come as a natural result of the publishing process, do not allow the product to get updated to the higher version of its included components ?
Best regards,
Shenny
