On Mon, 2019-09-02 at 08:38 +0200, Richard Levitte wrote:
> The dispute in PR https://github.com/openssl/openssl/pull/7853 has
> made it quote obvious that we have some very different ideas on when
> and why we should or shouldn't deprecate stuff.
> 
> What does deprecation mean?  Essentially, it's a warning that at some
> point in the future, the deprecated functionality will be removed.  I
> believe that part of the issue surrounding this is uncertainty about
> when that removal will happen, so let me just remind you what's
> written in our release strategy document:
> 
>   * No existing public interface can be removed until its replacement
>     has been in place in an LTS stable release. The original interface
>     must also have been documented as deprecated for at least 5 years.
>     A public interface is any function, structure or macro declared in
>     a public header file.
> 
> Ref: https://www.openssl.org/policies/releasestrat.html
> 
> I'd like to get this thread started with the following four questions,
> for as many of us to answer as possible:
> 
> 1. Why should we deprecate stuff
> 
> 2. Why should we not deprecate stuff
> 
> 3. When should we deprecate stuff
> 
> 4. When should we not deprecate stuff
> 
> Cheers,

(I know -project won't accept my mail; you can choose to include it in
a reply if you see fit).


I'd note that the question of *versioning* mechanisms is a very very
special case of "when to deprecate stuff". So much so as to almost make
it a completely separate question altogether.

My own favourite application is littered with checks on
OPENSSL_VERSION_NUMBER, and the occasional call to SSLeay() to check
for things that were fixed at runtime without an ABI change.

http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/openssl.c
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/openssl-dtls.c

A change to the versioning scheme is very much more than just another
thing that's been deprecated; it's a change to the very mechanism by
which we handle those deprecations. Changing that (and by extension,
rapidly deprecating it) requires a lot more work on the part of
application authors who want their code to build against whatever
version of OpenSSL may be present on the platforms they need to
support.



Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to