Not that I really wish to re-open this debate, but I want to make sure that people understand why projects and companies are moving towards automatic version range substitution.
The debate reduces down to arguing over what’s ideal vs. practical.
If I imagine an ideal developer with mental capacity and inclination to track what versions of what plugin has what change that they depend on and to always maintain version ranges accurately as changes to code are made, then clearly manual maintenance of every single version range produces best possible description of what a plugin is actually compatible with. In reality, I’ve never seen this happen with any degree of consistency. In common usage, the min version range is set based on what was in the target platform at the time the dependency was added and is never changed again. This is a very frequent source of bugs as dev target is frequently the latest platform. The max is ignored until the build breaks or an adopter/customer reports that they cannot install in certain configurations.
The reality of manual management of version dependency ranges is that “failed to install for no good reason” scenarios are far more likely than under automatic management. The system that we use for Sapphire was originally implemented for BEA/Oracle’s Eclipse-based product when we got fed-up with constantly having to fix bugs in version ranges. Since implementing the automated system, this category of bugs has disappeared entirely and what we ship precisely aligns with what we publicly say we support.
Of course, how you manage the oldest supported target is dependent on your project’s or product’s needs. For our commercial product, we are relatively conservative as we are on the hook for commercial support. For Sapphire, we’ve maintained Galileo GA as our oldest supported target. It is entirely possible for an Eclipse project to be very generous with what’s allowed as the min using an automated system. In fact it is easier to be sure of your generosity, if you are using an automated system.
In either an open source project or a commercial product, at some point there is a discussion and agreement on a policy for what a given release will support. Since introduction of the release train, these policies are typically described at the level of release train names. The difference between the automated system and the manual one is that with the automated system, you encode the policy in the build and your are done, while with the manual system you pray that combined actions of many developers don’t violate the policy.
Hope that helps set this matter in perspective.
- Konstantin
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent: Friday, September 23, 2011 11:03 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Strange dependency of EMF Edit UI
I know we've had this debate before, but I just wanted to jump in and say I think build-time substitution of version ranges is a bad idea. Clearly we lack tools that can accurately determine the correct range depending on our actual API usage of our required bundles/packages. In an ideal world we could generate *correct* ranges using tools. Without that, we have two options: 1) maintain ranges manually and risk that they are sometimes too wide 2) generate range at build-time and only allow consumers to use the versions that we built against. I think this second option is far too limiting. It is almost certainly disallowing configurations that actually work fine.
As component producers I think we should err on the side of being permissive rather than adding an arbitrary limitation here. Perhaps a company wants to take for example a part of EMF Juno and run it with a project from Indigo that is no longer in the release train. They can do all their own testing to prove to themselves that this combination works, but the build-time substituted version range won't allow it. This seems equivalent to, for example, disallowing your plugin running on anything but Windows 7 because that is the platform where you compiled and did all your testing (I will kindly disallow my users running on Linux because I haven't tested it myself and maybe it won't work).
Anyway, this probably isn't the place to rehash this debate - I just wanted to counterbalance the "build-time range substitution is ideal" viewpoint with the flip side of the argument...
John
Ed Merks <ed.merks@xxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx 09/23/2011 01:24 PM Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx> |
| To | cross-project-issues-dev@xxxxxxxxxxx | cc | | Subject | Re: [cross-project-issues-dev] Strange dependency of EMF Edit UI |
|
Konstantin,
That sounds totally ideal!
Regards,
Ed
On 23/09/2011 9:34 AM, Konstantin Komissarchik wrote:
In case this helps…
In Sapphire, we also use automatic insertion of version ranges into dependencies based on targets used at build, but we define multiple targets for the build to work with.
At the high level, the build takes three parameters:
1. List of targets. Currently “galileo,galileo-sr1,galileo-sr2,indigo,indigo-sr1,juno-38,juno-42”.
2. Oldest supported target. Currently “galileo”.
3. Recommended target. Currently “juno-42”.
The main build runs against the recommended target. A partial build is repeated against all other targets to check for problems that could be caught at compile time (such as use of API newer than the oldest target).
When it comes to inserting dependency version ranges, the min comes from versions found in the oldest supported target. The max comes from versions found in the recommended target plus an offset.
- Konstantin
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Merks
Sent: Friday, September 23, 2011 9:20 AM
To: cross-project-issues-dev@xxxxxxxxxxx; Eclipse Modelling Framework
Subject: Re: [cross-project-issues-dev] Strange dependency of EMF Edit UI
Kenn,
No, this definitely isn't a good thing. We must tolerate and even support 3.x so we must build and test against that. If we don't do that, we've basically made this decision for a large fraction (majority) of the release train which I don't feel is appropriate. The platform team has made it clear that 4.x must be compatible with 3.x so anything in EMF we discover (or downstream clients discover) doesn't work with 4.x will be something the e4 team needs to address. We need to change this as soon as possible...
Hopefully we'll be able to upgrade our builds so that the build is done and tested against 3.x and then retested against 4.x, but that's a longer term goal..
Regards,
Ed
On 23/09/2011 9:05 AM, Kenn Hussey wrote:
Michael,
The dependency versions for EMF are determined at build time based on the target it is built against. Since we built EMF 2.8 M2 against Eclipse 4.2 (given that the Juno train is being based on 4.x), the dependency versions are based on 4.2... We could switch back to building against 3.x but then we'd have less confidence that things work properly in 4.x...
Kenn
On Fri, Sep 23, 2011 at 10:16 AM, Wenz, Michael <michael.wenz@xxxxxxx> wrote:
Hi,
while switching the EMF version we use from 2.7 to 2.8 I noticed a strange dependency within org.eclipse.emf.edit.ui: the EMF 2.8 version has a plugin dependency to org.eclipse.ui.workbench[3.102.0,4.0.0).
The real problem appears when we try to build against the Eclipse 3.8 milestones update site for M2: there is only org.eclipse.ui.workbench in version 3.8.0 available which causes an unresolved plugin error. The Eclipse 4.2 milestones update site for M2 contains two versions of org.eclipse.ui.workbench (versions 3.8.0 and 3.102.0).
Any thoughts? It appears at least strange to me. What is the purpose behind?
Michael
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
