[gnutls-help] gnutls 3.7.7

Daiki Ueno ueno at gnu.org
Mon Sep 5 08:03:01 CEST 2022


Simon Josefsson <simon at josefsson.org> writes:

> Andreas Metzler <ametzler at bebt.de> writes:
>
>> On 2022-09-02 Simon Josefsson <simon at josefsson.org> wrote:
>>> Could you release the 3.7.x branch as 3.8.0 and declare that stable?
>>> That would effectively turn all code in 3.7.x (that is still around)
>>> into stable and supported code via the 3.8.x branch.  I'm happy to help,
>>> although it was years since I last did significant work on GnuTLS.
>> [...]
>>
>> Hello,
>>
>> did the Gnutls version number semantics change?
>>
>> Iirc for release in 3.x series at some point of time 3.n.m was declared
>> stable and when 3.n+1 was branched off as next, i.e. there were stable
>> releases of 3.0, 3.1, ….

That seems to be the case.  For example, 3.4.0 was released as
stable-next[1] and after a few iterations 3.4.x branch was marked as
stable[2] while 3.5.x was in development in the git master branch.

At some point during the 3.6.x cycle, however, the "next" concept has
been abandoned[1], and afterwards we repurposed it for 3.7.x
development.

> Sorry I don't really know what the semantics are, and incorrectly tried
> to document what I thought was the case here:
>
> https://gitlab.com/jas/gnutls/-/commit/e486e2f9a105d37fd73fcd312e9be6025d10221c

I agree following the semantic versioning scheme is a good idea (we
actually claim as we do[4]).  A drawback is that we can't incorporate
any backward incompatibile change without incrementing the leftmost
non-zero component i.e., "3" in this case.

> Then how about the following as the way forward?  This assumes nobody
> has the time to backport security fixes to the 3.6.x branch any more,
> and we are confident 3.7.x is stable.
>
> -|stable|3.6.x  |as needed       |
> -|next  |3.7.x  |bi-monthly      |
> +|stable|3.7.x  |as needed       |
> +|next  |3.8.x  |bi-monthly      |

Sounds good to me.  I guess all we need is to have a gnutls_3_7_x branch
and proper documentation of the current versioning scheme :-)

Footnotes:
[1]  https://gitlab.com/gnutls/gnutls/-/wikis/face2face-meeting-fosdem2019

[2]  https://lists.gnupg.org/pipermail/gnutls-devel/2015-April/007535.html

[3]  https://lists.gnupg.org/pipermail/gnutls-devel/2015-November/007801.html

[4]  https://bestpractices.coreinfrastructure.org/en/projects/330#changecontrol

Regards,
-- 
Daiki Ueno



More information about the Gnutls-help mailing list