[openssl-project] Release strategy updates & other policies

[Richard Levitte]

In message <20180924.100003.2155153469056385673.levitte at openssl.org> on Mon, 24 Sep 2018 10:00:03 +0200 (CEST), Richard Levitte <levitte at openssl.org> said:

> In message <79590c7b-98a4-4816-9eea-52f21b5e23e1 at default> on Sun, 23 Sep 2018 20:37:46 -0700 (PDT), Paul Dale <paul.dale at oracle.com> said:
> 
...
> > Some thoughts about this:
> > Should we deprecate functions at a major release or with LTS
> > releases?
> 
> I'm not sure I'd tie that to LTS releases specifically.  Our current
> practice (as seen in the name of our deprecation macros) is to
> deprecate stuff (not just functions...  there are certain openssl app
> commands that I'd like to get rid of) at major release boundary.
> 
> (Incidently, semantic versioning FAQ suggests that deprecation can as
> well happen in a minor release, possibly even preceding a major
> release)
> 
> Also, we must consider if we see deprecation as an incompatible API
> change.  If we do, deprecation can most certainly only happen at major
> release boundary.  My 0.02 SEK is that we should, if we consider the
> configuration option 'no-deprecated' and how deprecation at minor
> release boundary could lead to surprise breakage.

I've been thinking a bit more on this part, and am wavering...  with
our slow pace (it's usually a couple of years between MINOR releases),
deprecating only at MAJOR release boundaries may be quite a stretch to
predict what should go and what shouldn't.  After all, deprecation is
only tacking on a warning that something is going to disappear in a
predictable future, if at all possible to do.

We may have to regard 'no-deprecated' as a development configuration
option only, basically classifying it as "all bets are off".

Cheers,
Richard

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