api break from CTBase update

[jbcaillau]

@PierreMartinon check #121

New release needed

@ocots a few thoughts:

• API break so CTBase.jl release should have been 1.0.0?
• I could (should...) have provided aliases / patches in CTBase.jl to ensure compat. with CTDirect.jl
• typical example showing that global test in our OptimalControl.jl / CTxxxx.jl hierarchy are in order; maybe could be included in OptimalControl.jl CI

[ocots]

Semantic versioning: https://semver.org/#spec-item-4

[ocots]

@PierreMartinon check #121

New release needed

@ocots a few thoughts:

• API break so CTBase.jl release should have been 1.0.0?

No. Semantic versioning: https://semver.org/#spec-item-4

• I could (should...) have provided aliases / patches in CTBase.jl to ensure compat. with CTDirect.jl

Patch version Z (x.y.Z | x > 0) MUST be incremented if only backward compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.

• typical example showing that global test in our OptimalControl.jl / CTxxxx.jl hierarchy are in order; maybe could be included in OptimalControl.jl CI

??

[jbcaillau]

Thanks @ocots for the new release

@ocots a few thoughts:

• API break so CTBase.jl release should have been 1.0.0?

No. Semantic versioning: https://semver.org/#spec-item-4

Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.

From the same ref.:

Going from nlp_constraints to nlp_constraints! is an incompatible API change

• typical example showing that global test in our OptimalControl.jl / CTxxxx.jl hierarchy are in order; maybe could be included in OptimalControl.jl CI

??

CTBase.jl tests were OK, not those in CTDirect.jl anymore; could have broken instantly OptimalControl.jl for anyone willing to install. Actually, was still OK since CTBase.jl has not yet been updated to v0.10: