On 04/03/2019 12:43, Julian Reschke wrote: > 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?
I think is more or less the same level of confusion we currently have. One thing is the API/OSGi export versions and the other are the product version. For example Oak 7.34 could introduce an API change but only for a specific package while leaving untouched the rest of the code base. For us it will be a non-compatible change and forcing us to branch but to a keen eye it may be a compatible change as the product using Oak is not using that specific package. By keeping the two concept separated will help, IMO, to instruct tools in what is actually compatible for a specific product. > I'm not sure how to read this? Is your proposal to start with 2.0 as > first stable release? No. The first stable will be 1.12, followed (hopefully) by 1.14. D.
