[gnutls-devel] GnuTLS | RELEASES.md: document the releases policy (!1011)

[Development of GNU's TLS library]

Nikos Mavrogiannopoulos commented on a discussion on RELEASES.md: https://gitlab.com/gnutls/gnutls/merge_requests/1011#note_176812102

> +In the GnuTLS project there are at most two ongoing releases, one marked as
> +'stable' and one marked as 'next'. The former is always present and
> +supported, while the latter is introduced on the discretion of the
> +development team.
> +
> +For both release branches all the rules in [CONTRIBUTING.md](CONTRIBUTING.md)
> +apply, but in principle the 'stable' release is more conservative in new features,
> +while the 'next' branch allows for mild behavioral changes. The 'stable' branch
> +always provides API and ABI compatibility, while the 'next' branch may on exceptional
> +cases change the API.
> +
> +
> +|Branch|Version|Release interval|
> +|:----:|:-----:|:--------------:|
> +|stable|3.6.x  |bi-monthly      |
> +|next  |-      |                |

I haven't thought about the cadence nor when could that release be. At the moment we have the milestone without any dates and potential issues to address: https://gitlab.com/gnutls/gnutls/milestones/20

There is no "process" for starting a next branch, but would it make sense that anyone can propose forking and starting the next branch, and during that proposal we discuss cadence and what gets in from the disruptive changes?

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1011#note_176812102
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20190531/96971caf/attachment-0001.html>