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 .
This code will get more attention if it is known to be released, and
more attention means more testers and more feedback.
 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
Size: 948 bytes
Desc: not available
More information about the Gnupg-devel