Achilles-Versioning

Until now, versioning for Achilles has been quite chaotic. From now on, the strategy for version change is defined below.

Versioning rule

Achilles version is defined using 3 numbers: major. medium. minor

• major: a change in major version is triggered by

  • a migration to a new Cassandra major version ( 2.1 → 3.0 for example)
  • an important breaking API change

• medium: a change in medium version is triggered by

  • an introduction of a new feature/API
  • a removal of deprecated API/feature
  • a migration to new Cassandra medium version ( 2.0.x → 2.1 for example)

• minor: a change in minor version is triggered by

  • bug fixes
  • internal code refactoring without impact on the API or client behavior (except for deprecated features, see below)
  • migration to new Cassandra minor version ( 2.0.10 → 2.0.11 for example)
  • migration to new Java Driver version

API deprecation rule

Before being removed, an API/feature/type/annotation will be marked as @Deprecated and will co-exist with the
new/replacement API/feature/type/annotation for at least 3 minor versions.

If you're using an API/feature/type/annotation marked as deprecated, expect it to be removed:

• on the next major version
• on the next medium version
• on the next 4^th minor versions counting from the current

Any deprecation will be properly documented in the Changelog and the Java Doc redirects to the appropriate new API/feature/type/annotation