Versioning¶

Coco Platform Version¶

The Coco Platform version is the version of the tool that users use. Each version of the Coco Platform will correspond to a version of all of the Coco Platform tools, including the Eclipse plugin, the VScode plugin, and the command-line tooling.

The Coco Platform is versioned according to semantic versioning, meaning that:

• Releases where only the last digit changes (more precisely, from X.Y.Z to X.Y.Z' such as 1.2.3 to 1.2.4) are called patch releases and include only bug fixes relative to the previous version. These versions should always be backwards-compatible unless the fix required prohibiting some Coco code (such cases are rare).
• Releases where the middle digit changes (more precisely, from X.Y to X.Y' such as 1.2 to 1.3) are called minor releases. They can include both bug fixes and new features. As above, these versions should be backwards-compatible unless the fix required prohibiting some Coco code (such cases are rare).
• Releases where the first digit changes (more precisely, from X to X' such as 1 to 2) are called major releases. These can include bug fixes and new features, but unlike other changes can include backwards-incompatible changes; for example, it might be the case that a major version will drop support for an older language standard (see Language Standard below).

New releases of the Coco Platform do not necessarily mean that there will be major changes to either the Coco syntax or to the generated code. These are versioned separately as discussed below.

Cocotec will only provide support for certain versions of the Coco Platform based on new releases. When a new release occurs, certain releases will be declared as unsupported as per the following schedule (unless your license agreement indicates otherwise):

• When a new major release occurs, after 2 years all versions less than the new release will be declared as unsupported.
• When a new minor release is made, after 6 months all versions less than the new release will be declared as unsupported.
• When a new patch release is made, all versions less than the new release will be declared as unsupported.

For the avoidance of doubt, the above summary is only supplied for ease of reference and is not binding in any way; the support schedule as specified in your license agreement has precedence over any guarantees made or implied above.

Language Standard¶

The language.standard setting in the Coco.toml file can be used to specify which version of the Coco language should be accepted by the tool. Changes to this normally indicate that the syntax of the language will change in some way, potentially in a non-backwards compatible manner. New language standards will be introduced relatively rarely.

Language standards are numbered according to a severity-based approach:

• A change from X.Y to X.Y+1 (e.g. 1 to 1.1) will indicate a relatively minor change, such as the addition of certain keywords to the language, or additional identifiers being prohibited in Coco code. These changes should be easy to resolve and it is likely that most Coco code will be compatible with the new standard with no changes.
• A change from X to X+1 (e.g. 1 to 2) will indicate a major change that would require many files to be changed. These changes may be more complex to resolve and it is likely that most Coco code will need to be modified. In these cases, automated tooling will be provided to migrate code as easily as possible.

Not all versions of the Coco Platform tools will support all language standards. For example, it is possible that a future major release of the Coco Platform will remove support for older language standards.

Generated Code Version¶

The individual code generators are also versioned according to a severity-based technique as per the language standard:

• A change from X.Y to X.Y' (e.g. 1 to 1.1) will indicate a relatively minor change, such as a minor change to the generated code that may require a small number of handwritten files that use the generated code to be updated. The expectation would be that upgrading to a new minor version of the code generator should not take more than a few hours even on very large projects.
• A change from X to X' (e.g. 1 to 2) will indicate a major change that would require many files to be changed. These changes may be more complex to resolve and it is likely that handwritten code that uses the generated code may need to be more substantially changed.

Not all versions of the Coco Platform tools will support all code generators or all code generator versions. For example, it is possible that a future major release of the Coco Platform will remove support for an entire language or a code generator version that has been superseded.