[openssl-project] Release strategy updates & other policies

[Richard Levitte]

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.

Yes.

> 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
> release.

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.

Yes.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/