On Sat, 22 Sep. 2018, 2:29 am Viktor Dukhovni, <[email protected]> wrote:
> > > > On Sep 21, 2018, at 12:14 PM, Matt Caswell <[email protected]> wrote: > > > > I support Richard's proposal with an epoch of 1. > > Grudgingly I would accept an epoch in the 3-8 range. > > I would oppose an epoch of 2. > > I can live with that, though it might mean that a minority of > applications will interpret (based on obsolete nibble extraction) > It isn't obsolete nibble extraction - that is the documented way to get the major version. In the header file and in the API docs. This is changing things as we document the format of that number currently and some code does use that. What Richard proposes is a breaking change conceptually and it doesn't need to be one. We can get to semantic versioning and also not break existing documented usage. But what we will be doing is following a versioning scheme that states precisely what it means for API changes. It says nothing specifically about ABI changes unless you take the view that ABI == API when reading the document too. If that is the case then our current practice of allowing ABI breakage with minor release changes (the middle number we document as the minor release number) has to change. And anyone depending on checking the minor version number for ABI compatibility will break. Tim.
_______________________________________________ openssl-project mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-project
