Re: #10388
> On Nov 14, 2019, at 9:15 AM, Matt Caswell 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. -- Viktor.
Re: #10388
On 14/11/2019 13:43, Salz, Rich wrote: > *>*I’m more concerned about adding these to 3.0. It means we’ll have to > support the new API for a long time and it is one which we are currently > trying to move away from. > > > > Will you? Have you already decided that 3.0 is an LTS release? > Otherwise, you have the LTS burden and when the rest of ENGINE goes > away, this does as well. > Quoting the release strategy: "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. Matt
Re: #10388
>I’m more concerned about adding these to 3.0. It means we’ll have to support >the new API for a long time and it is one which we are currently trying to >move away from. Will you? Have you already decided that 3.0 is an LTS release? Otherwise, you have the LTS burden and when the rest of ENGINE goes away, this does as well.
Re: #10388
On Thu, Nov 14, 2019 at 08:41:57AM +, Matt Caswell wrote: > I think that we should not add them to 1.1.1 without also adding them to 3.0. Yes. > OTOH if you have a 1.0.2 application that uses these things then not having > them would represent a barrier to moving off of 1.0.2. And it doesn't add > that much burden to us from the perspective of moving these things to the > legacy bridge, because we've got to do all the other "meth" calls anyway and > these are just two more. My take is that we should just add them, and then deprecate them in 3.0.0 when it comes to deprecate all the existing related functions. Having a few more members of the same family to deprecate is not a burden. The deprecation won't be any harder for having an extra handful of code-points. This is based on reports that these are basically missing accessors, not a substantial new feature, and there is some plausible need for them, now that the relevant structures are opaque. -- Viktor.
Re: #10388
On 14/11/2019 06:39, Dr Paul Dale wrote: > With reference to #10388: https://github.com/openssl/openssl/pull/10388 > > This PR intends to add missing APIs to 1.1.1. I’m fine with this being > considered a bug and adding them. > > > I’m more concerned about adding these to 3.0. It means we’ll have to > support the new API for a long time and it is one which we are currently > trying to move away from. > > > Thoughts or comments anyone? I think that we should not add them to 1.1.1 without also adding them to 3.0. I'm in two minds about it. I'm not particularly keen on adding new functions only to deprecate them again in the next release. Also, I wonder how widely used this would be? These things have not been available since 1.1.0 came out 3 years ago and its taken until now for someone to notice. OTOH if you have a 1.0.2 application that uses these things then not having them would represent a barrier to moving off of 1.0.2. And it doesn't add that much burden to us from the perspective of moving these things to the legacy bridge, because we've got to do all the other "meth" calls anyway and these are just two more. Matt
