[openssl-project] Release strategy updates & other policies
matt at openssl.org
Tue Sep 25 10:53:48 UTC 2018
On 25/09/18 11:48, Richard Levitte wrote:
> In message <dee8621c-7071-4bf3-3ce0-dadaff9df682 at openssl.org> on Tue, 25 Sep 2018 11:30:39 +0100, Matt Caswell <matt at openssl.org> said:
>> On 25/09/18 11:13, Tim Hudson wrote:
>>> On Tue, Sep 25, 2018 at 8:07 PM Matt Caswell <matt at openssl.org
>>> <mailto:matt at openssl.org>> wrote:
>>> 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>
>>> > <mailto: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
>>> > 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.
>>> In semantic versioning those are MINOR releases. The API has changed in
>>> a backward compatible manner.
>>> They cannot be called PATCH releases - those are only for internal
>>> changes that fix incorrect behaviour.
>>> If you change the API you are either doing a MINOR or a MAJOR release.
>>> Now I think the flexibility we added during 1.1.0 when the MAJOR change
>>> was to make APIs opaque was a different context where our API remained
>>> unstable (in semantic terms) yet we did a release (for other reasons).
>>> Under semantic versioning, 1.1.0 would have been called 2.0.0 and we
>>> would have had to batch up the accessor API additions into a 2.1.0
>>> release and not have those included in any 2.0.X PATCH release.
>>> It is quite a change under semantic versioning in some areas as it
>>> basically requires the version to reflect API guarantees.
>> I don't think we should batch up accessor API additions. Or in fact any
>> others. We should release them at the right time as we do now. A move to
>> semantic versioning shouldn't change that. That has implications for the
>> way we manage branches and support periods/LTS.
> Most of all, it may mean more frequent MINOR releases.
>> I suggest that we only create new branches for a MAJOR version number
>> change. We define the support periods/LTS status relative to the major
>> version number. For a given supported major version we may update the
>> MINOR or PATCH number at any time dependent on whether we've added any
>> new functions or not. What we now think of as a "letter" release could
>> be either a MINOR or a PATCH release under semantic versioning
>> (dependent on what we've changed/added). We continue with the same
>> policy of not adding new features to a stable branch (except where
>> necessary to fix a bug).
> You are contradicting yourself. If we only make new branches for
> MAJOR version number changes, then it will be allowed to add new
> functionality in them, because that's allowed with a MINOR version
> number change.
You misunderstand me. Yes, its allowed that we can under semantic
versioning rules. I'm saying we shouldn't.
> I understand the wish to reduce the number of branches to maintain, we
> must just make sure we know what we're talking about.
> If we would start branching MAJOR releases only, then we'll need some
> kind of policy on what branches are still being developed (i.e new
> MINOR releases are allowed in that branch) and what branches are in
> maintenance mode only (i.e. only new PATCH releases allowed).
All branches are in maintenance mode except master. Typically we only do
PATCH releases for a branch. If we've needed to add a function to a
branch (e.g. a missing accessor) then we make it a MINOR release.
Otherwise we don't add new functionality (as now).
More information about the openssl-project