<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Sep 25, 2018 at 7:23 PM Richard Levitte <<a href="mailto:levitte@openssl.org">levitte@openssl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So what you suggest (and what I'm leaning toward) means that we will<br>
change our habits.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>For example:</div><div>- adding an ASM implementation for performance reasons - is that PATCH or MINOR</div><div>- changing an ASM implementation for performance release - is that PATCH or MINOR</div><div><div>- adding an ASM implementation to get constant time behaviour - is that PATCH or MINOR</div><div>- changing an ASM implementation for constant time behaviour - is that PATCH or MINOR</div><div><br></div><div>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).</div><div>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.<br></div><div><br></div><div>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 :-)</div><div><br class="gmail-Apple-interchange-newline"></div></div><div>Tim.</div><div><br></div><div><br></div></div></div>