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). PATCH versions should never change an API. 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. 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. Tim
_______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
