On 01.03.2019 10:48, Davide Giannella wrote:
Good morning everyone,
it looks like the strategy proposed in a previous post about future
branching and strategies[0] is good with everyone. Now it's time to
discuss the version number schema we'd like to adopt.
Referring to https://semver.org/ which goes along what I was taught in
school we could apply the following rules on version numbers
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.
Hm - doesn't that introduce potential confusion with the package export
versions, for which Semver is relevant only?
Given that any new release will always include both bugs and features,
point 3 does not really apply to us. We're therefore left with a schema
of MAJOR.MINOR.
Additionally, even if not strictly required I would keep the even/odd
schema we currently have. With the exception that we won't ever release
Yes.
odd versions as by definition we account any release as stable.
All given we have the following examples:
1.12, 1.14, 1.16, 1.18, 1.20, ..., 1.26
Now let's say we have to branch at 1.26 time we would create a branch
`svn/.../branches/1.26` that will produce thereafter 1.26.0, 1.26.1, etc.
Trunk will become: 2.0, 2.2, 2.4, 2.6, etc.
Thoughts?
Davide
I'm not sure how to read this? Is your proposal to start with 2.0 as
first stable release?
Best regards, Julian
