kfogel@collab.net wrote:
>I'm reposting this question because maybe not everyone is reading the
>thread 'Re: 0.32, the "1.0" milestone, and the 1.0 release.'
>
>The proposal:
>
>After the 0.32 release, let's have a feature freeze and concentrate on
>bugfixing until the 1.0 release. This period of bugfixing will be our
>Beta; there may or may not be interim milestones during it, depending
>on what we find.
>
>
There might be a misunderstanding here - but it sounds like what
subversion refers to as a 'beta', most other projects refer to as a
'release candidate'. Are there release candidate(s) planned in addition
to beta(s)?
I would strongly recommend creating a branch for 1.0 once we begin
packaging of the first 'release candidate', whether that is really this
beta or not.
Normally release candidates are a cooling-off period for code; you have
all the features, you think they all work as intended, and you want your
testing group to try and prove you wrong. This is very reactive coding.
If we get fifty bugs filed on the first release candidate, I can see the
point of focusing all the development community on fixing them. I also
would be worried about major flaws in the 1.0 release. If we get five,
there is no reason to hold up post 1.0 development - the people who are
focused on 1.0 are more than capable of reacting to these bugs as they
come in. It is also possible that even this subset of people would be
idle while waiting for bugs to come in, and could focus on post-1.0
features.
My question is - how unstable do you think subversion is? Do you think a
1.0 release is going to be limited by the speed bugs can be closed, or
by the amount of time it takes for the testers attracted by the beta and
release candidates to fully test the product?
-David Waite
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 3 20:20:38 2003