Simon Josefsson <si...@josefsson.org> writes: > Andreas Metzler <ametz...@bebt.de> writes: > >> On 2022-09-02 Simon Josefsson <si...@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 _______________________________________________ Gnutls-help mailing list Gnutls-help@lists.gnutls.org http://lists.gnupg.org/mailman/listinfo/gnutls-help