[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[mdt-ocl.dev] Version plans / API compatibility
|
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