Good afternoon everyone,
here's a summary of what we discussed in previous threads:
https://lists.apache.org/thread.html/768807eed3379dc08921a1510264136ffe4a7a1230d9ca7881cc0a59@%3Coak-dev.jackrabbit.apache.org%3E
https://lists.apache.org/thread.html/c29415060be41938bdb7bfeac3e79a5d7efaf51dff84461657dff462@%3Coak-dev.jackrabbit.apache.org%3E
*Strategies*
- trunk will be considered stable
- only releases from trunk other than existing branches
- any previous release from trunk will be automatically deprecated
*Branching*
Branching will not happen other than in specific circumstances. Such as,
but not limited to:
- incompatible API changes
- incompatible JVM changes
- updates to dependencies that breaks backward compatibility
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.
*Frequency*
Every two months with room, as usual, for early cuts in case or urgent
needs.
*Version Numbers*
- Released versions will be in the format of `Major.Minor.Patch` where,
as rule of thumb we will increase
1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible
manner, and
3. PATCH version when you make 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`
If I missed anything or any objections please reply. I will update docs
in the near future.
Cheers
Davide
