[openssl-project] Release strategy updates & other policies
levitte at openssl.org
Tue Sep 25 09:23:30 UTC 2018
In message <CAHEJ-S5_ZbjQdL-FAXLLbT_UdvhwwK1fYQ2cWxML8hm+t+MOMA at mail.gmail.com> on Tue, 25 Sep 2018 18:39:43 +1000, Tim Hudson <tjh at cryptsoft.com> said:
> A fairly common approach that is used is that you can only remove something that has been
> marked for deprecation at a MAJOR release version boundary.
> That is entirely independent of the semantic versioning view of things - which also happens to say
> the same thing (that adding a deprecation indication is at least a MINOR release and the removal
> is at a MAJOR release).
Yes, hence the subject change (good call on Paul)
> PATCH versions should never change an API.
> So we start warning whenever it is that we decide to deprecate in a MINOR release, but any actual
> removal (actual non-backwards compatible API change) doesn't come in place until a MAJOR
Well, *so far* we have done deprecation at MAJOR release boundary
only, at east post 1.0.0. The diverse DEPRECATEDIN_ macros show that.
So what you suggest (and what I'm leaning toward) means that we will
change our habits.
> I see marking things for deprecation is a warning of a pending non-backwards-compatible API
> change - i.e. that there is another way to handle the functionality which is preferred which you
> should have switched across to - but for now we are warning you as the final step before removing
> an API at the next MAJOR release. We haven't committed we will actually remove it - but we have
> warned you that we expect to remove it.
Richard Levitte levitte at openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
More information about the openssl-project