On 14.11.19 20:40, Viktor Dukhovni wrote:
On Nov 14, 2019, at 9:15 AM, Matt Caswell <[email protected]> wrote:
"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."
So the functions we're talking about don't yet have a replacement -
there will be one in 3.0. So presumably they will be documented as
deprecated in 3.0. So we have to support them for at least 5 years from
the release of 3.0.
I think that when we're deprecating an entire family of *related* accessors
(for the same structure) that have been in place for some time, the addition
of a missing member of that family is reasonably interpreted as not resetting
the support clock on the entire family. We can still remove them all as though
the missing members of the family had been in place all along.
That is, we should (and if that requires a policy update and vote so be it) be
able to interpret the rules based on the "spirit" (intent) without getting
unduly burdened by the "letter", where common sense would suggest that we're
getting the intended outcome.
I don't think we need a reinterpretation, or even a change, of the existing
policy for
this specific case, since already now the *entire* engine api can only be
deprecated
in version 3.0 and removed afterwards according to the policy cited by Matt.
We can simply add the missing accessor as bugfix to 1.1.1 and 3.0, and
immediately
deprecate it on the latter. The only difference will be that we end up with n+1
deprecated
functions instead of n (for some natural number n) for version 3.0.
Even after 3.0 is released and as long as 1.1.1 LTS is still supported, we can
proceed
in the same way without violating existing policies.
Matthias
