"Mark Phippard" <markphip_at_gmail.com> writes:
> No one wants to see us release software with bugs in it, but I think
> our goal should be to have a great GA release, not great alpha
> releases. The point of the alpha release is to get users to try it
> and report back on the problems that our test suite does not catch.
> We can't do that if we do not release them. Using this same line of
> reasoning, I would rather see us release these without the formal
> signature process. If a bad bug that is fixable is found, then just
> roll a new release. If we are not doing all the signature stuff it
> should be relatively easy to get a new release tarball up. After all,
> Hyrum is currently posting nightly tarballs. I think the benefit of
> the named alpha/beta releases is that the it easily shows up in svn
> --version and that makes it easy to talk to users and tell them when a
> problem is known and has been fixed.
For alphas, I think Mark's ideas are quite sane.
In fact, the demarcation between "alpha" and "beta" can be that we
sign the betas (and don't call them official until signed). The RC
tarballs would follow the same rules as betas, it's just that the
understanding is it's more serious, because it's going to be the
actual same bits as the release if it passes muster.
(The above makes me wonder if there's any real need for betas at all,
but we can cross that bridge when we come to it.)
Anyone object if I adjust
http://subversion.tigris.org/hacking.html#release-stabilization
to reflect this philosophy of getting alphas out for testing more
easily? (Hyrum should still roll a new one if he can, I think, but
that doesn't mean testing should stop until then, that's all.)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-26 00:07:35 CET