11.2.1 Versioning

Haxelib uses a simplified version of SemVer. The basic format is this:


These are the basic rules:

  • Major versions are incremented when you break backwards compatibility - so old code will not work with the new version of the library.
  • Minor versions are incremented when new features are added.
  • Patch versions are for small fixes that do not change the public API, so no existing code should break.
  • When a minor version increments, the patch number is reset to 0. When a major version increments, both the minor and patch are reset to 0.


  • "0.0.1": A first release. Anything with a "0" for the major version is subject to change in the next release - no promises about API stability!
  • "0.1.0": Added a new feature! Increment the minor version, reset the patch version
  • "0.1.1": Realised the new feature was broken. Fixed it now, so increment the patch version
  • "1.0.0": New major version, so increment the major version, reset the minor and patch versions. You promise your users not to break this API until you bump to 2.0.0
  • "1.0.1": A minor fix
  • "1.1.0": A new feature
  • "1.2.0": Another new feature
  • "2.0.0": A new version, which might break compatibility with 1.0. Users are to upgrade cautiously.

If this release is a preview (Alpha, Beta or Release Candidate), you can also include that, with an optional release number:



  • "1.0.0-alpha": The alpha of 1.0.0 - use with care, things are changing!
  • "1.0.0-alpha.2": The 2nd alpha
  • "1.0.0-beta": Beta - things are settling down, but still subject to change.
  • "1.0.0-rc.1": The 1st release candidate for 1.0.0 - you shouldn't be adding any more features now
  • "1.0.0-rc.2": The 2nd release candidate for 1.0.0
  • "1.0.0": The final release!