LTS policy?

[Werner Koch]

On Wed, 30 Aug 2017 12:53, bernhard at intevation.de said:

> Can you explain more what you mean by "no new features"?
> Sometimes is hard to say if a change is necessary and thus a fix or if it 
> optional. And fixes could break something as well.

Example for new features would be support for the v5 key format or a new
symmetric encryption mode.  This will not go into 2.2.0.  However, if it
will be easy to implement and does not require major changes to existing
code paths it may happen that read-only support for such things will be
backported to 2.2.  This depends on our future release schedule and on
whether a backport would help to deploy new algorithms or protocol
extension.

In general we will push our activity more into the direction of
integrating gpg into other applications.  If this requires tweaking
things in 2.2 and a stable 2.4 is not yet on the horizon, we will do
that in the 2.2 branch.

But there won't be any disruptive things in 2.2.  If major changes are
required they will be tested in a 2.3 branch and then released with 2.4.  

> Will you create a 2.3.0 branch for all new features or only for those that 
> break some compatibility?

To get forward with RFC4880bis we need to write some code, it is likely
that this will happen in a 2.3 branch (i.e. in master).


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170831/430eba7a/attachment.sig>