Re: [rt-pmc] Feature version range policy

[Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>]

Hey Markus, 

First, I really appreciate you bringing this topic up in the PMC list.  Awesome. For context, at the end of Helios there was a case where some EMF features were build using Buckminster with the approach that you suggest.  At the time it was quite late in the release cycle so the approach was abandoned pending further discussion of the flavor that you raise now.

The bug you cite refers to at least part of that discussion in this area (see comment 4). In particular, there has been discussion in the following threads
	http://dev.eclipse.org/mhonarc/lists/pde-dev/msg01799.html
	http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg04201.html

To my knowledge there has not been any further discussion.

Fundamentally there are two issues at stake.  
1) Feature semantics.  If you have a feature that says Includes X and then the p2 metadata indicates an inexact range, the p2 metadata does match the feature. This will be the source of numerous and subtle problems. I am not saying that Feature semantics are perfect but we can't just go around changing implementation in incompatible ways.  It would be like having a concrete class not conform to its interface/API. You/others can seek to develop new semantics etc but simply ignoring those that are in widespread use is not a recipe for success.

2) Determinism.  Using version ranges introduces non-determinism.  For example, say there is an "ECF" feature that currently *includes* the ecf.foo and ecf.bar bundles. After being built those inclusions would be bound to exact versions of ecf.foo and ecf.bar (say 1.2.3.xxx for both). Further, the ECF feature itself would have an exact version, say 1.3.6.yyy. Given that, a consumer could provision their system (runtime or target) with ECF 1.3.6.yyy and know exactly what they will be getting regardless of whatever else is available.  Deterministic.

Say now that we relax the version range in the p2 metadata to effectively have a *requirement* on ecf.foo and ecf.bar.  The resultant metadata would say that the ECF.feature.group iu requires the bundles with a range of say [1.0.0, 2.0.0). The feature IU itself would still have a precise version number say 1.3.6.zzz.  Now the consumer goes to provision ECF 1.3.6.zzz. The versions of ecf.foo and ecf.bar that get provisioned will depend on the particular versions that are available at the time of the operation. Add a newer repo and you will get newer versions.  If a repo happens to be offline at that precise moment you could get an older version.  You might even get a mix of new and old.  Non-deterministic.

Furthermore, two people doing the exact same operation may get different results due to repo visibility or other constraints in our respective systems.  Similarly for one person doing the same operation twice.  Finally, in a repo with multiple versions, consumers will never be able to provision anything but the latest so folks would not be able to install Indigo once Indigo SR1 comes out.

To be sure, some of the semantics just described *can* be useful.  Simply getting the latest is very cool and if you are in a scenario with managed repos you can control what gets installed by controlling repo contents. In my understanding however, this is not the general case.

Summary, evolving the way we define and manage and tool groups of bundles etc. is likely something that needs to be addressed.  This is a topic that will be affected by and will impact many areas in Eclipse from build to p2 and PDE to the simultaneous release and our consumers.  As such, the topic should be brought up in the Architecture Council or other widely scoped forums.

Jeff

p.s., just to be clear for everyone the "*pde.feature.range.generation* property is a Buckminster setting.  This capability  to map feature inclusions onto inexact ranges is not something defined or supported by PDE despite "pde" being in the property name.


On 2010-08-12, at 8:22 AM, Markus Alexander Kuppe wrote:

> On 08/10/2010 05:28 PM, Jeff McAffer wrote:
>> Just to be clear, if you are talking about the ranges for feature *requirements* then fine.  If you are talking about changing *inclusions* to be compatible *requirements* then there is a larger topic to discuss.
> 
> Jeff,
> 
> we intend to relax the includes:
> 
> "*pde.feature.range.generation*
> This flag controls whether or not to generate version ranges for
> included features and bundles found in the feature.xml file. The default
> setting is true, i.e. generation is enabled." [0]
> 
> So if this is part of a bigger discussion, where do we find it?
> 
> Markus
> 
> [0] https://bugs.eclipse.org/bugs/show_bug.cgi?id=309147#c2
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc