The consensus seems to be to add the deprecated API to 3.0. I’ve removed the hold.
Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 15 Nov 2019, at 10:40 pm, Matthias St. Pierre > <matthias.st.pie...@ncp-e.com> wrote: > > > > On 14.11.19 20:40, Viktor Dukhovni wrote: >>> On Nov 14, 2019, at 9:15 AM, Matt Caswell <m...@openssl.org> 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