In message <20180924.100003.2155153469056385673.levi...@openssl.org> on Mon, 24 Sep 2018 10:00:03 +0200 (CEST), Richard Levitte <levi...@openssl.org> said:
> In message <79590c7b-98a4-4816-9eea-52f21b5e23e1@default> on Sun, 23 Sep 2018 > 20:37:46 -0700 (PDT), Paul Dale <paul.d...@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 levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
