[openssl-project] What's a new feature, vs what's a fix?

Matt Caswell matt at openssl.org
Mon Jan 22 09:31:52 UTC 2018



On 21/01/18 07:40, Richard Levitte wrote:
> This may need being rehashed, as it seems we don't have a concensus.
> 
> Our versioning policy stipulates that released versions of OpenSSL
> should only be updated with fixes, that new features should go into
> new releases (right now, 1.1.1 will be the next new release, while
> 1.1.0 has already been released and is only updated).
> 
> The question that keeps coming up, through comments like the attached,
> is "what do we mean by 'new feature'".  I have been surprised at times
> by what others have considered a 'new feature', and obviously, I can
> surprise as well.
> 
> I think that it's clear to every one that added APIs is a new feature.
> 
> I think that it's clear to every one that added new functions is a new
> feature...  most of the times (the exception is when a fairly obvious
> function is missing in a newly released API).
> 

In my mind even simple new functions (getters/setters) are a new
feature. Its just that, as a matter of pragmatism, we have decided to
allow them (effectively they are a "fix" for a broken design).

> But then we have other items where it's not quite as clear, and
> opinions seems to differ, such as:
> 
> - is a new config target a new feature?  I think that most of us have
>   agreed that it is, but am not entirely sure everyone sees it that
>   way.

IMO, yes. A new target is a new feature.

> 
> - is a new config option a new feature?  I have argued that it is, but
>   am not at all sure we have a consensus.

Yes, I'd say it was.

> 
> - is a new C macro to indicate if a certain feature is desirable or
>   not a new feature?  I actually have no clue, which is also the
>   reason I raised the question in the PR.
>   A side question is why this was coded as a direct C macro
>   configuration and not as our other config options, and in that case,
>   why we should consider it differently from the usual config options.

I don't have the context for this to really know - but as a general rule
I'd say anything new like this in a public header is probably a feature.
OTOH what is the motivation for adding it? For missing getters/setters
the motivation is we are adding back in the capability to do something
which was intended to be there in the first place but was inadvertently
broken due to opacity. Pull #4901 is a slightly different version of this:

https://github.com/openssl/openssl/pull/4901

Here we are proposing to add a new SSL_OP_ flag into 1.1.0 because
something that you used to be able to do in 1.0.2 is no longer possible
due to opacity.

If we are adding a feature in order to "fix" something that should work
but doesn't (especially if you used to be able to do something but now
can't), then this is a fairly strong argument for using the exception.
As with all of these things though there is always going to be a grey
area where we will have to exercise our judgement.

Matt



More information about the openssl-project mailing list