Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] Version plans / API compatibility


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.


        Ed Willink

Back to the top