|[mdt-ocl.dev] Version plans / API compatibility|
HiI 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 releaseUsing 0.9 nicely precedes 1.0 and hopefully prevents anyone using the code accidentally.
Regards Ed Willink
Back to the top