| Re: [epp-dev] Role, importance, or use of pre-req feature versions? |
Before the technical discussion, comes a more general discussion around: What is it we are delivering, what is the level of support offered, and how much flexibility are we ready to give and as such headache that we setting ourselves up for?
Let me explain:
If each EPP Package includes a unique version of its dependencies (no range), then we are somewhat locking down what the user can do. He/she will not be able to update to a newer version of components of the package independently (e.g. replace the version of the platform, EMF, etc). He will only get those pieces once we make available an update of the package. From our point of view of producers this has the advantage that when a user reports a problem against a particular version of the package, we know exactly what it is he is running (modulo the stuffs he could have installed on top) and we do not let the user burn himself trying out combinations that are known to not work together, or never been tested. This is really much of a "product" mindset.
Now the drawback of this "product" approach is that we are gating the access of new content to our users, and therefore it forces packages to be rebuilt or feature patches to be delivered when a component wants to deliver a critical update which is a little bit more overhead for package maintainers. But this is doable and it is pretty much what product teams of member companies are doing (e.g. IBM).
The other approach, where dependencies are not strictly specified, let's call it "cowboy" delivery, obviously offers more possibilities of combination for the end user since he can pretty much mix and match content from any release but also from newly available content from Milestone site of the Helios builds. However this makes it much harder for tracking bugs since you have to figure out the complete line up of things the user is running (p2 helps here since you can get the most recent profile file). Some of the problems resulting from this mix and match approach (e.g. missing internal, API not defined, etc.) could probably be avoided by having each team be way more specific about their version numbers in their plug-ins and features (for example to ensure that they can not be installed against this older version of the plug-in that did not had this API or this internal), which means again more burden on each component team. (though I would agree that this is a direction we need to go long term anyway).
So are we "products" or "cowboys"?
Personally, I would vote for the EPP packages to be "products" because I believe that our audience expect "products" despite the careful wording put around each release.
What are you?
PaScaL
David M Williams ---05/15/2009 03:52:26 PM---I know that the latest versioning guidelines recommend not to use "require
From: | David M Williams <david_williams@xxxxxxxxxx> |
To: | epp-dev@xxxxxxxxxxx |
Date: | 05/15/2009 03:52 PM |
Subject: | [epp-dev] Role, importance, or use of pre-req feature versions? |
