jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: [DISCUSS] Branching and release: version numbers
Date Mon, 04 Mar 2019 12:43:35 GMT
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

Mime
View raw message