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
