There are a couple sides to this. One is that if you have Product X v
1.2.3.20100923, that should mean something. If you allow ranges as described,
then two users installing X 1.2.3.20100923 may not get the same actual software
installed. Variation is introduced for example, if user 1 has access to a
different set of repos than user 2 or there is a network error for user 1 but
not user 2 or the single repo changed between when user 1 and user 2 did their
install.
Of course, these behaviours *could* also be exactly what you want but certainly
some folks free at this non-determinism as a support nightmare.
Anyway, looking at features, they allow for things to be *included* or
*required*. Included things have exact version ranges while required things
have, generally, wider ranges. Traditionally the notion was that on install,
the things *included* by the feature were installed whereas the things
*required* merely had to be there. Early update manager didn't even help you
find/get/install the required things. That was goofy so we provided a means
for users to say "yeah, get the required stuff also". Now with p2 we do this
automatically without involving the user. So much for context...
It would be reasonable to allow ranges on product content but it would also
force the product designer to be very aware of the consequences pointed out at
the beginning of this message. I honestly don't know what people would do
naturally or what guidance we could/should give them (e.g., what's the
default?).
Back to your original topic, there is also the possibility of producing new
versions of your product that identify the new versions of the components.
Product production and distribution in p2 is very light weight and users would
see this as incoming new versions of the product (that they know about) vs
changes to random components (that they may well not even know exist). What
would you say as the user of some banking product if told that there was a new
version of EMF? "WFT?!"
Scenarios vary. If that does not work for you, you can insulate your product
by making it consist of one feature. In that feature, *require* everything that
you want to be updatable, include the stuff you want to be fixed (or put this
stuff directly in the product). The product will be bound to the one version
of your container feature and the container feature can use ranges. Beware the
problems outlined above with non-determinism. Note that you can also usethe
p2.inf file to do this. Andew Niefer did a couple blog posts on this a while
ago
http://aniefer.blogspot.com/2009/07/composing-and-updating-custom-eclipse.html
http://aniefer.blogspot.com/2009/07/composing-and-updating-custom-eclipse.html
Good luck
Jeff
On 2010-09-23, at 12:13 PM, Yousouf, Shenol wrote:
> 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
>
> _______________________________________________
> p2-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
