[mdt-ocl.dev] Compatibility Support

[Alexander Igdalov <Alexander.Igdalov@xxxxxxxxxxx>]

Hi Team,

After analysing the new standard draft we must now decide how exactly we are going to support both OCL 2.2 and compatibility with the previous implementation. I see two options:

A. Make a separate set of plugins per each implementation. Evolving this idea, we can now make a new branch of OCL plugins called 'OCL_2_0_support' (a better name is welcome). Thus, in Helios, we would build both 1.4.0 (from the branch) and 2.0.0 plugins (from HEAD).
+ It is clear how to do it. We can start right away.
+ It is easy. All we need to do is being accurate with versions in manifest files and change labels/ids in the UI examples so that the implemenations would be distinguishable in the UI. We will also have some releng issues.
+ It is a finite task. Once we do it, ideally we can forget about OCL 1.4.0 and focus on the new standard. Practically, we will have to care about things like updating dependencies, running builds, etc. Perhaps, we will have to fix some of the must-do items for the release train - like introducing capabilities. But the effort will be minimal.
+ It gives more freedom for the new implementation. For instance, there would be no problem to drop some public method or change some other API whether internal or external. We introduce the changes in HEAD while the branch is always backwards compatible.
+ Simplicity and clarity of code. The code will not contain numerous if-clauses checking whether it is this or that standard and then doing different actions per each case.
+ Little effort to eventually drop 1.4.0+ support; just to exclude the corresponding plugins/features from the release train (e.g. after the next two releases).
- We will double the amount of plugins. For those who run both implementations in a single Eclipse memory requirements will also increase (but not dramatically I suppose)
- Releng activities will probably become more complicated. More headache for the releng guy (i.e. me).

B. Combine both standards in a single set of plugins.
+ Probably the total amount of code (responsible for what we have by now) will not increase significantly.
+ Releng would be the same as before.
- Unclear how to do it. In each case we will have to invent some workaround - add new metamodels, combine two parsers and possibly two LPG implementations, create numerous if-clauses in code. Moreover, what would be the condition of these if-clauses? IOW, what will we check to distinguish the standards: a system property, some flag in the environment, some external context, preference page, etc.? I feel it would be difficult.
- It is an infinite task (at least until the 1.4.0+ support is discontinued). One will always have to keep the previous implementation in mind when fixing a bug. Each bug fix will need to answer the question "will it be backwards compatible?" and decide how to make it backwards compatible.
- (Backwards compatibility) bugs. Since this approach is more complicated it will probably produce more bugs, including compatibility issues.
- Less freedom for the new implementation. If we change some internal API the clients may experience problems. We will always have to keep this in mind deciding what to do in each case.
- Code polluted with numerous checks and branches supporting two standards.
- Considerable effort to eventually drop 1.4.0+ support.

Considering these pros and cons of each approach, I vote for variant A.

Cheers,
Alex.