[mdt-ocl.dev] Version plans / API compatibility

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

I added API tooling to the 'examples' plugins and started linearizing 
some of the branches I had been experimenting with while waiting to 
decide on a release/version policy.

I 'successfully' merged changes to eliminate many CS attribution 
classes, but compatibility requires that the old classes remain. 
@Deprecated and throw new UnsupportedOperationException(). Is that 
really compatible?

The change to merge OpaqueExpression into ExpressionInOCL is much harder 
requiring numerous known safe casts. Possible but unpleasant.

The change to simplify the NameExpCS grammar blows everything away.

I was hoping to get the OpaqueExpression / ExpressionInOCL merge done 
since that is assumed by the OCLinEcore debugger.

But realistically the conclusion has to be that maintaining an illusion 
of Luna API compatibility while migrating to cleaner OCL 2.5 API will 
probably double the development effort and degrade the code in the 
meantime. Not justifiable.

So current plan (Pivot version numbers)

3.4.2, 3.4.3. Minor changes based on 3.4.1.

3.5 not an option since API compatibility too hard for real progress.

0.9 for 'existing' and refactored' code in transition to OCL 2.5

1.0 for Mars release

Using 0.9 nicely precedes 1.0 and hopefully prevents anyone using the 
code accidentally.

    Regards

        Ed Willink