|[eclipse.org-architecture-council] Fwd: [cross-project-issues-dev] Check your feature includes in Helios|
If you contribute features to Helios then please read and consider this.
Recently there has been a discussion on the PDE mailing list about the "slackening" of feature *includes* dependencies. A brief summary:
Features can include and require things. When you include something you end up with a tight binding to a particular version. When you require something you can spec a range of acceptable versions. Features were specified this way to ensure that installing a particular feature version would unambiguously and repeatably result in the exact same *included* features and plugins being installed.
There seems to be a few projects in Helios that are slackening this characteristic and using various means to create p2 metadata that has imprecise ranges for *included* elements. The net effect is that once consumers have multiple versions of prerequisite bundles available (e.g., once Helios SR1 ships, some other repo is added to a user's context, ...) installing these tweaked features will give ambiguous results and will not be repeatable.
While it is accepted that tight bindings can be challenging and p2 has much more underlying power and there are many interesting usecases, this is a departure from a long standing API and consumer understanding. Consumers creating and shipping products based on the features we distribute in Helios will fully expect the exact version specifications on their included components be used at provisioning time. Changing includes to use ranges breaks the API contract and should not be allowed in the repo.
Accordingly, we should all ensure that the p2 metadata correctly match the expressed intent in the authored features. Particularly WRT version and version range specifications. This would actually be a useful repo sanity check.
cross-project-issues-dev mailing list
Back to the top