On Tue, Sep 25, 2018 at 8:07 PM Matt Caswell <m...@openssl.org> wrote:
> On 25/09/18 10:58, Tim Hudson wrote: > > On Tue, Sep 25, 2018 at 7:23 PM Richard Levitte <levi...@openssl.org > > <mailto:levi...@openssl.org>> wrote: > > > > So what you suggest (and what I'm leaning toward) means that we will > > change our habits. > > > > > > Adoption of semantic versioning will indeed require us to change our > > habits in a number of areas - that is the point of having a single clear > > definition of what our version numbers mean. > > > > I also do think we need to document a few things like what we mean by > > bug fix compared to a feature update as there are items which we could > > argue could either be a PATCH or a MINOR update depending on how we > > describe such things. > > Sometimes we need to add a function in order to fix a bug. How should > this be handled? e.g. there are 60 functions defined in > util/libcrypto.num in the current 1.1.0i release that weren't there in > the original 1.1.0 release. > In semantic versioning those are MINOR releases. The API has changed in a backward compatible manner. They cannot be called PATCH releases - those are only for internal changes that fix incorrect behaviour. If you change the API you are either doing a MINOR or a MAJOR release. Now I think the flexibility we added during 1.1.0 when the MAJOR change was to make APIs opaque was a different context where our API remained unstable (in semantic terms) yet we did a release (for other reasons). Under semantic versioning, 1.1.0 would have been called 2.0.0 and we would have had to batch up the accessor API additions into a 2.1.0 release and not have those included in any 2.0.X PATCH release. It is quite a change under semantic versioning in some areas as it basically requires the version to reflect API guarantees. Tim.
_______________________________________________ openssl-project mailing list firstname.lastname@example.org https://mta.openssl.org/mailman/listinfo/openssl-project