[openssl-project] Release strategy updates & other policies

[Matt Caswell]

On 25/09/18 10:58, Tim Hudson wrote:
> On Tue, Sep 25, 2018 at 7:23 PM Richard Levitte <levitte at openssl.org
> <mailto:levitte at openssl.org>> wrote:
> 
>     So what you suggest (and what I'm leaning toward) means that we will
>     change our habits.
> 
> 
> Adoption of semantic versioning will indeed require us to change our
> habits in a number of areas - that is the point of having a single clear
> definition of what our version numbers mean.
> 
> I also do think we need to document a few things like what we mean by
> bug fix compared to a feature update as there are items which we could
> argue could either be a PATCH or a MINOR update depending on how we
> describe such things.

Sometimes we need to add a function in order to fix a bug. How should
this be handled? e.g. there are 60 functions defined in
util/libcrypto.num in the current 1.1.0i release that weren't there in
the original 1.1.0 release.

Matt


> Getting those things documented so we can be consistent is a good thing
> IMHO. The specifics of which we place in PATCH and which we place in
> MINOR are less important than being consistent in handling the same item.
> 
> For example:
> - adding an ASM implementation for performance reasons - is that PATCH
> or MINOR
> - changing an ASM implementation for performance release - is that PATCH
> or MINOR
> - adding an ASM implementation to get constant time behaviour - is that
> PATCH or MINOR
> - changing an ASM implementation for constant time behaviour - is that
> PATCH or MINOR
> 
> For all four of the above examples the API is the same (assuming that
> the low-level APIs are not actually exposed in the public interface for
> any of these).
> And deciding on those depends how you view performance - is it a bug
> that something runs slower than it could - or is it a feature.
> 
> Good arguments can be made for always MINOR or for PATCH - but I think
> we should have a clear view on how we will handle such things going
> forward given the OMC members have differing views on the topic and we
> shouldn't end up with different handling depending on which members in
> which timezone are awake for a given pull request :-)
> 
> Tim.
> 
> 
> 
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>