We aim at keeping this frequency for releases. However dates may slip according to needs
For a full discussion around these topics see in oak-dev archives.
Branching will not happen other than in specific circumstances. Such as, but not limited to:
In short: most probably it will always be around non-backward-compatible changes
Anyhow in such cases the branching is not automatic and will be discussed between PMCs a best course of actions. Alternatives may be a different way to implement something breaking.
Released versions will be in the format of Major.Minor.Patch
where, as rule of thumb we will increase
MAJOR for incompatible API changes
MINOR for new backwards-compatible functionality PATCH for backwards-compatible bug fixes.
We'll keep the even/odd schema
Any new official release will be always even: 1.12.0, 1.14.0, 1.16.0, ..., 1.124.0
A release will always be with a patch number (the last part) of .0
. This ease OSGi deployments.
Diagnostic builds will be cut with the odd version and -Rxxx
such as 1.15-R12345
.
In case of branching the increased part will always be the PATCH so: 1.16.0
, 1.16.1
, 1.16.2
, etc.
In case of branching the diagnostic build will follow the current pattern: 1.16.5-R12345