In message <73e9cd06-575e-4cde-b137-95179b07b...@dukhovni.org> on Wed, 26 Sep 2018 13:24:11 -0400, Viktor Dukhovni <openssl-us...@dukhovni.org> said:
> > > > On Sep 25, 2018, at 9:51 AM, Matt Caswell <m...@openssl.org> wrote: > > > > 5.0.0 > > 5.0.1 (bug fix) > > 5.1.0 (add accessor) > > 6.0.0 (new feature) > > 6.0.1 (bug fix) > > 5.1.1 (bug fix) 6.0.2 (bug fix) > > 5.2.1 (add accessor) > > 6.1.0 (add accessor) > > Previously, we could add non-triviall features in "z+1" of "x.y.z", > with a stable ABI moving forward from "x.y.z" to "x.y.(z+1)". > > Thus, e.g. 1.1.1 is a feature evolution of 1.1.0. With this, we seem > to lose the ability to produce a manifestly (forward) ABI-compatible > feature release, that's a drop-in replacement for a previous release. Your interpretation is incorrect, but that's because you're mixing up our current practice (which is wrong according to our docs), which is shited right compared to semantic versioning (and our docs). We have done none-trivial feature additions in "z+1" BECAUSE WE CALLED THAT A MINOR FEATURE RELEASE. In semver terms, we should have done "y+1" instead. (incidently, our letter release correspond to "z+1" in semver terms) BTW, "add non-trivial features" isn't really a useful terminology. The semver trigger for MINOR version bump is "add new functionality to the public API", regardless of if it's trivial or not. > I would have expected to have 5.1.x as an ABI compatible upgrade of > 5.0 with non-trivial new features. > > The trivial API updates in stable releases (new accessors for forward > compatibility, ...) would go into the micro version along with the > bug fixes. And should be made for the same reason. This is absolutely wrong in semantic versioning. Compatible APi *changes* are allowed in PATCH level releases (what you call micro versions). And strictly speaking, this doesn't even necessarily comply with our current practice, see this FAQ text: Letter releases (e.g. 1.0.1a) can only contain bug and security fixes and no new features. Minor releases change the last number (e.g. 1.0.2) and can contain new features that retain binary compatibility. I noticed that you mentioned "drop-in"... the way we've designed things so far, our minor releases produce libraries that can replace the same libraries from earlier minor releases in the same major series. > In the case of new accessors, their visibility should conditioned > the user defining a suitable macro to make them visible. Their > purpose is to facilitate compiling code that's forward-ported > to a later release, but needs to still work with the stable > release. Otherwise, there really should be no feature changes > in stable releases. This is where opinions seem to diverge. I have had a change of heart, new accessors should have trigger a new minor release and not been added as a letter (micro) release. What I see happening is, of course, that we will have more frequent minor releases, and that minor release may work as an upgrade from an earlier patch release. The latter will essentially depending on how we decide to branch going forward (Matt, branching on major releases starts to make sense, incidently... I'm not totally convinced yet, but...) Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project