Duktape follows Semantic Versioning:
The "public API" to which these rules apply include:
experimental
. API calls implemented as macros are part of
the public API, but any internal calls the macros make are not. Changing
an API call from a function call to a macro (or vice versa) is considered
a compatible change (but is not done in patch releases).Duktape
object and other Ecmascript extensions, as documented on duktape.org.The following are not part of the "public API":
experimental
.extras/
directory).When a patch version is released, the following things are guaranteed:
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.
Releases use the form (major).(minor).(patch), e.g. 1.0.3.
Development pre-releases use the form (major).(minor).(patch)-alpha.(number), e.g. 1.3.0-alpha.2. The form 0.(minor).0 was used for development pre-releases before the 1.0 release.
DUK_VERSION
and Duktape.version
provide version
identification using a single number computed as:
(major * 10000 + minor * 100 + patch)
,
then subtracting one for development pre-releases.
Note the limitations for development pre-releases:
Development pre-releases shouldn't be used in production, but the current
DUK_VERSION
and Duktape.version
number provides
a useful approximation for version comparison: an alpha release will compare
smaller than the actual release, but higher (or equal) than a previous release.
The table below provides some examples, in ascending version order:
Version | Pre-release? | DUK_VERSION & Duktape.version |
Notes |
---|---|---|---|
0.12.0 | yes | 1200 | Pre-release before 1.0 release. |
1.0.0 | no | 10000 | |
1.3.0-alpha.1 | yes | 10299 | Identified like 1.2.99, first 1.3.0 development pre-release. |
1.3.0-alpha.2 | yes | 10299 | Identified like 1.2.99, no difference to 1.3.0-alpha.1. |
1.3.0 | no | 10300 | |
1.3.2 | no | 10302 | |
1.3.3-alpha.6 | yes | 10302 | Identified like 1.3.2, no difference to 1.3.2 release. |
1.3.3 | no | 10303 | |
2.0.0-alpha.3 | yes | 19999 | Identified like 1.99.99. |
2.0.0 | no | 20000 |
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.
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.