2.1 beta or release

Daniel Kahn Gillmor dkg at fifthhorseman.net
Fri Oct 24 17:25:24 CEST 2014

On Fri 2014-10-24 10:51:20 -0400, Werner Koch wrote:
> shall I do another beta before doing the release or shall I declare it
> ready, wait for some folks to report problems from a git build, and do
> the release after fixing them?

having explicitly tagged explicit releases (beta or otherwise) makes it
more straightforward for me to package it for debian, so i prefer that
over trying to package the git head.

> In any case I expect that 2.1.0 will have a couple of build and runtime
> problems.  We simply do not enough testers.  A 2.1.1 will thus likely
> follow in shortly after 2.1.0.

Is the implication that if we call it 2.1.0, the 2.0.x branch will no
longer be supported?  Will there be a separate "master" branch created
that will also need to be supported?  In practice, we're maintaining 3
branches right now: 1.4.x, 2.0.x, and master -- if calling the release
2.1.0 just says "master is ready to be used by the public", and doesn't
mean we have to support an extra branch, then I think 2.1.0 is
preferable, even if there are known regressions [0].

This code will get more attention if it is known to be released, and
more attention means more testers and more feedback.



[0] for me, the worst regression is the export-reset-subkey-passwd
situation, which is blocking my personal adoption; i'm sorry i haven't
had time to fix it yet.  Any help fixing it would be welcome.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20141024/b0395156/attachment-0001.sig>

More information about the Gnupg-devel mailing list