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
