So much for having said... ;) > Please let's focus on the process here and ignore the version number.
In-line as usual On 20/02/2019 14:54, Marcel Reutegger wrote: > Hi, > > On 20.02.19, 13:21, "Robert Munteanu" <[email protected]> wrote: >> On Wed, 2019-02-20 at 10:45 +0000, Davide Giannella wrote: >>> - Any previous oak release will be automatically deprecated. What has >>> been already branched and released still stays there. This applies >>> only >>> to future releases. >> So say we release 1.12 from trunk and then 1.12.1 from trunk. Does that >> mean that 1.12 becomes instantly deprecated? > I wouldn't call it deprecated, but 1.12.1 will be the new recommended > version. This specific situation is very similar to how we do maintenance > releases. The most recent release from a maintenance branch is the one > we recommend. True. By not having a branch we cannot deliver something limited to a bug fix. So 1.12.1 will be the next good one with all the bells and whistles. It will therefore happen that if we have 1.12.2 and someone reports something against 1.12.0 the first thing will be to see if it's reproducible in trunk. We won't have any branch and the user will have to use the latest and greatest. >> Do we even plan to make minor releases such as 1.12.1 or will 1.13 >> immediately follow after 1.12? > That's a good question. In my view we could make micro releases based > on what has changed since the last minor release. If it's just bug fixes, > release as 1.12.1 otherwise move to 1.14. > > Note the even minor version. To avoid confusion, we could still say only > even minor versions are considered stable release. Even though we > wouldn't create releases anymore with uneven minor version numbers. I wanted to keep the version number discussion separate because it involves more questions than answers. However I agree with Marcel. Rule of thumb IMO should be: only micro releases other that there are changes justifying the minor change. I would stick to even minor numbers as well to ease the understanding keeping the same concept of even/odd - stable/unstable. By not having any more unstable we won't have any more odd releases. Tanking from https://semver.org/ I think this could help us deliver new version numbers and is what I was taught in school "few" years ago :) Given a version number MAJOR.MINOR.PATCH, increment the: 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. Given the above rules (if fine with everyone) we'll have a versioning schema that makes us increasing `major` every time we need to branch. Because for us branching will be always around backward incompatible changes. Additionally we won't have `patch` numbers because, for the above discussion, any release will probably always have a mix of features and bug fixes. So we may end up in having 1.12, 1.14, 1.16, etc. Davide
