Community
Participate
Working Groups
It should be possible for a product to provide a root feature that bundles together many features and yet still allow those contained features to be separately updated. Currently the orthogonal issues of how to update, vs. how to bundle have incorrectly been tied together. This allows the feature to look like a product, yet still allow its bundled elements to be updated. This is also important in the product upgrade scenarios.
I have put together a design note with a proposed 2.0.1 approach for this and several related defects. See the doc below (have to paste the split line together to get the whole url). http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-update- home/doc/feature_extensions.html
Sorry, got the url wrong http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-update- home/doc/working/feature_extensions.html
Let us assume that we allow an additional attribute 'match' to be specified in the 'includes' element. 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)?
Attribute 'match' has been added. Code for reconciliation has been changed. released in 2.0.2 dev stream
The problem will be addressed as specified in the following document: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-update- home/doc/working/feature_extensions.html
Correction: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-update- home/doc/working/feature_extensions_2.html
*** Bug 22879 has been marked as a duplicate of this bug. ***
Implemented - ready to test.
Tested
