[gnutls-devel] GnuTLS | Clarify or improve our supported releases meaning (#588)
Development of GNU's TLS library
gnutls-devel at lists.gnutls.org
Sun Oct 21 08:37:19 CEST 2018
> @ametzler any thoughts on that? The situation we have now is that at
> any ABI breakage the previous release (e.g., 2.12.x, 3.3.x) became a
> de-facto LTS release as distributions like debian/rhel rely on it
> cannot move forward. So first question is, would you as debian
> maintainer be interested in a collaborative maintainership of a
> similar LTS branch in the future? Ie. bring the debian patches if any
> and thus also have a say on what other patches go in and on how long
> would that be open? (and such offer would be open to other
> distributions) Would that make sense from your perspective?
to be honest I do not think there is a lot *I* could contribute there.
Also we are quite limited in what changes are acceptable for Debian
stable - just fixing security issue and important bugs. This simply does
not match with how GnuTLS stable releases work, they include fixes for
minor issues, too. Up until 3.6 cherry-picked new features from the
development branch were also included, but with the new symbol-versioning
policy  afaiui this has changed, new features only can appear in *one*
set of releases. (Unless there is an ABI break).
> The second (related) question is that if we keep ABI fixed to the one
> in 3.4.x, would it make sense to create a similar LTS release in the
> future after 3.3.x is considered out of support?
For Debian we currently have 3.5.8 in stable and 3.3.8 in oldstable, due
to the timing of the respective releases we have not shipped 3.4.x in
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/588#note_110534148
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnutls-devel