Versioning

Semantic versioning

Duktape follows Semantic Versioning for official releases:

The "public API" to which these rules apply include:

The following are not part of the "public API" versioning guarantees:

When a patch version is released, the following things are guaranteed:

Development builds made from Duktape repo are not official releases and don't follow strict semantic versioning.

Experimental features

Some new features and API calls are marked experimental which means that they may change in an incompatible way even in a minor release.

Features may be marked experimental e.g. because they are useful but incomplete, or because the best design is not obvious and it's useful to gather some feedback before committing to the design. Typically a feature is experimental for one minor release and then, after the necessary changes, becomes a fully supported feature.

Version naming

Releases use the form (major).(minor).(patch), e.g. 1.0.3.

DUK_VERSION and Duktape.version

DUK_VERSION and Duktape.version provide version identification using a single number computed as: (major * 10000 + minor * 100 + patch), then subtracting one for development builds (not official releases) made from Duktape repo.

Note the limitations for development builds:

Development builds shouldn't be used in production, but the current DUK_VERSION and Duktape.version number provides a useful approximation for version comparison: a development build will compare smaller than the actual release, but higher (or equal) than a previous release.

Examples

The table below provides some examples, in ascending version order:

Version DUK_VERSION &
Duktape.version
Notes
0.12.01200Development build before 1.0 release.
1.0.010000
1.2.9910299Development build before 1.3 release.
1.3.010300
1.3.210302
1.3.310303
2.0.020000

Maintenance of stable versions

There's no long term maintenance policy yet: stable versions will get bug fixes (patch releases) at least until the next stable version has been released, and there has been some time to migrate to it.

Incompatible changes

The general goal for incompatible changes is that an application relying on old, unsupported features will fail to build. It is preferable to have the build fail rather than to be silently broken. This means for example that:

This is not a hard rule, but the default guideline.