This is also true.
Can this work?
stage 1. Ready for testing release candidate (July 6)
stage 2. Testing and bug fixing X number of weeks or we wait to have
the major bugs fixed if any
stage 3. Official announcement for release
...
maintenance releases ...
What do you think?
Adrian
On July 6-th we are done and we say is ready for testing
On Jul 1, 2008, at 10:13 AM, Bogdan-Andrei Iancu wrote:
Hi,
We are all aware that from bug fixing and testing nothing relevant was
done for preparing the release (95% of the commits were related to
docs
or spelling).
So, I say the current trunk version is not a something to be
considered
ready for a release. If you force a data before fixing at lease the
major know bugs, we will:
1) compromise the quality and reputation of the project
2) it will be useless - nobody will want to use a poor quality
release
For any changes in the release policy (like candidate, alpha), I
suggest
to do it before planing a release and not during the release itself -
changing the rules of the game during the game may be highly confusing
and with poor results.
Regards,
Bogdan
Henning Westerholt wrote:
Hi all,
according to our initial schedule [1] we want to release 1.4.0 this
friday.
Because of the recent delays in the development i want to ask if
this date is
valid anymore.
I'm not sure how much testing of the actual development branch has
been done.
In some areas its perhaps sufficient, but for the server as a whole
probably
not. In the past the stabilisation phase was two month, we aggreed
to change
this to one month because of the past experiences that no real
testing were
done.
I think this is caused to some extend from our lack of user
involvement in
this state of development. Other projects has a more formal process
with some
alpha and beta versions before a stable version is released, for
example.
Anyway, we should reach a descicion.
I can think of several options now:
1) release 1.4.0 as soon as possible, fix all bugs as they get
reported in the
stable branch (similar to 1.3.0). Try to fix already open bugs on
the tracker
before the release. For this option i propose the 11th July as date.
2) Review all existing issues reported on the tracker and fix them.
Release
1.4.0 when ready.
3) release 1.4.0-alpha this friday, ask for testing on the user
list. Release
a beta/ stable according the bugs/ user experiences in a few weeks
from now.
What do you think?
Henning
[1] http://lists.openser.org/pipermail/devel/2008-June/013909.html
_______________________________________________
Devel mailing list
Devel@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/devel
