In the last few weeks I've run into two products that I'm working with that try to maintain backwards compatibility with previous Eclipse releases. That is, while working on an upcoming release they want to make sure their plug-ins work all they way back to Eclipse 3.4 (one case only to 3.5, but still).
And I understand the desire of that. I've found old plug-ins that I want to use which claim support for 3.5 say and I'm very happy when they install and run with 3.6. And I'm even happier when the install into and work with M4 of Indigo. It's a difficult decision to pull back from the latest and greatest to get some needed functionality. It doesn't seem right.
But for these products, one thing should get in the way of that, the CDT. We don't claim 100% API compatibility from year to year. There's a reason why we're working on CDT 8.0 while the platform is still 3.7. And there's lots of practical reasons behind that, the main one being that we don't want to be tied to bad decisions made in the previous release. The more external tools we try to integrate and new features and just general clean up, we need to make things better even if we have to change APIs to do it.
No it's not fair to the community, but then we really haven't had a lot of push back from the community to stop that behavior. We can only assume they're reasonably happy to follow along, releasing their plug-ins with a fixed line up of Platform and CDT. And maybe that's it. The CDT ecosystem isn't set up where vendors plug-in their CDT integrations into each other. We tend to be competitors at that level, not partners.
But I think that is going to change very soon. Of the two products I mentioned, one is more mature and I guess CDT just happens to be backwards compatible enough that things just work. I'm a bit surprised but it relies mainly on debug APIs which we've been pretty careful to preserve. But without guarantees, I fear what they are doing.
The other is new and I'm kinda getting in on the ground floor. I have to decide which version of CDT to support. The rest of the stack supports back to Eclipse 3.5 which would be CDT 6. But then I want to do something good with CDT scanner discovery to properly set up the indexer. There should be some nice fixes in the upcoming CDT 8 for that. So do I have two versions of this thing? That's kind of where it goes, which is why I'm hoping we get these APIs locked down soon, for the good of all integrators who are facing the same decisions.
One thing to note is that there are ways for plugins to be compatible with multiple others, using the new and upgraded features when possible but not breaking for old versions; even if they don't claim 100% API compatibility.
ReplyDeleteI'll take the example of Acceleo as it is what I work on and know. Acceleo is dependent on OCL, which isn't API compatible between its 1.3 (Eclispe 3.5) and 3.0 (Eclipse 3.6) releases. Yet even with that, Acceleo is compatible with Eclipse 3.4 - OCL 1.2, Eclipse 3.5 - OCL 1.3, Eclipse 3.6 - OCL 3.0... and so on.
Of course, someone that uses Acceleo 3.0 in Eclipse 3.4 won't have access to the best of what we offer : it depends on OCL 3.0 which can only be accessed when in Eclipse 3.6.
We've chosen to have the "incompatibility" to only show at the source level : if you try and compile Acceleo 3.0 in Eclipse 3.4, you will see that some of our classes simply don't compile. Yet at runtime, these classes won't ever be called, and the user will never see any breakage.
So yes, I am of the side that thinks backward compatibility is extremely important for products, as important as is forward compatibility (though I believe that last one is less easy to ensure). And it is not a dream, just compromises to make in the way we code :p.
Doug, also remember that some of the commercial versions of Eclipse, like IBM Rational Software Architect are always a few version behind in there official products. RSA 7.0 = Eclipse 3.2, RSA 7.5 = Eclipse 3.4 etc.
ReplyDeleteMany big corporations like to pay for the extra functionality in there so prescribe such products.
So if you want to be used in there as well, you need the backward compatibility at least until the current and current -1 versions of the commercial implementations you want to support.
Tip: offer the backward compatibility in a PAID version, or offere PAID compatibility layer: the work is less exciting, but the customers for it have deeper pockets.
And I guess that's another part of the difference in the CDT community. I could care less if RSA used CDT, especially an old version. I would only care if that enabled contributions from the RSA team that help me with Wind River Workbench. But if we're working on different versions, whatever.
ReplyDeleteHi Doug!
ReplyDeleteAPI backward compatibility is one thing, but user's data (project, settings, etc...) compatibility is another.
It's very important for our customers to be able more old projects forward, for example.
We're in the process of migrating to CDT 7 at the moment, but my expectation was that there's nothing that would break user's data compatibility, or that there wouldn't be a converter available to handle this migration.
Is this a correct assumption?
Thanks :)