[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] Handling product suites
|
Added a couple of <pm> </pm> comments
Thanks,
-----------------------------------
Peter Manahan
WebSphere Tools
Build/Install and
Product Architecture
------------------------------------
manahan@xxxxxxxxxx
Dejan
Glozic/Toronto/IBM@IBMCA To: platform-update-dev@xxxxxxxxxxx
Sent by: cc:
platform-update-dev-admin@ Subject: [platform-update-dev] Handling product suites
eclipse.org
09/05/2002 08:44 PM
Please respond to
platform-update-dev
The current implementation of Eclipse Update in 2.0.0/2.0.1 releases
provides for tight feature hirearchy that fit the traditional product
structure well. Specifically, all features in the hirearchy are referenced
using exact IDs and versions, and only the root feature can drive update
server location. Update is 'all or nothing'.
We received some requests to relax the spec a bit to provide for the
declaration of product 'suites'. These suites would be formed of individual
features (products) that act as a single product, yet can be individually
updated (in other words, act like root features).
We are seeking feedback before considering this request (see
http://dev.eclipse.org/bugs/show_bug.cgi?id=21351). If implemented, it
opens up many interesting problems, most of which evolve around the extent
of the service contract. In a 'tight' product hierarchy, a product feature
with a specific version includes exact versions of its child features. It
is not possible to upgrade individual included features because that
invalidates the exact referencing imposed by the structure.
<pm>
Even without product suites we should still be allowed to use
match rules on features just like plugins. A large product could
have multiple features and may choose to to lock down the update site
with a root feature. That should not imply that the root feature has
to change every time a child feature is updated. In fact in most cases
we wouldn't want the root feature to change.
</pm>
Let us assume that we allow an additional attribute 'match' to be specified
in included feature referencing. This attribute would follow similar
referencing rules used by dependent plug-ins (equivalent, compatible,
greatedOrEqual etc.). In theory, this relaxation of the cross-feature
referencing would allow us to update child features without breaking the
parent reference (as long as the upgraded version still resolves according
to the 'match' attribute).
What this solution implies is that the root-level feature that allows some
'wiggle' space to its children to upgrade individually may not be able to
guarantee that they all work together. With each member feature
individually updatable, possible combinations of versions may result in
inability of the original suite provider to guarantee anything and
therefore deletage any conflict resolution to providers of the child
features (products in the suite).
We are seeking feedback on the following: if each individual feature
(product) in a suite can be independenly updated (possibly from its own
update site), what expectations (if any) can be had regarding the stability
of the suite as it randomly evolves through upgrades of the constituting
products. Does a suite version make any sense (since it is invalidated as
soon as the first member product is upgraded under it)?
<pm>
It makes sense but the suite needs the control. By default the root feature
should
block the update sites of the child features. In the case of a suite
the suite owner may wish to allow a child feature's update site to be
visible.
In that case there needs to be a way for the root feature to selectively
permit
exposure of child feature sites.
Combine this with matching to allow the suite to determine which updates
will be allow.
The root feature can specify a child feature with a matching rule of say
"equivalent"
and then expose the child feature's update site. As long as the updates
match the rule the
child feature can update itself. Once though the updates would break the
match rule eclipse
should not allow the child feature to be updated with the breaking match
change.
</pm>
Regards,
Dejan Glozic, Ph.D.
Application Development
D2/MY7/8200/MKM
IBM Canada Ltd.
Tel. 905 413-2745 T/L 969-2745
Fax. 905 413-4854
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev
