In message <> 
on Tue, 25 Sep 2018 18:39:43 +1000, Tim Hudson <> 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.


> 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.


Richard Levitte
OpenSSL Project
openssl-project mailing list

Reply via email to