On Tue, Sep 25, 2018 at 08:13:53PM +1000, Tim Hudson wrote: > 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.
We might need to add this to multiple branches at the same time. Assume that we have a 2.0.5 and 2.1.2 version. And in both versions we need to add that a new function, what should the new versions be? My understanding is that you can't actually do it. Kurt _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
