In message <cahej-s5_zbjqdl-faxllbt_udvhwwk1fyq2cwxml8hm+t+m...@mail.gmail.com> on Tue, 25 Sep 2018 18:39:43 +1000, Tim Hudson <[email protected]> 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 [email protected] OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-project mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-project
