I have read through the release plan. I can't imagine that we will
have a true code freeze, as there could always be bug fixes that it is
determined must be fixed. A code freeze on features and non-critical
bugs (graphical glitches and the like) makes sense, but fixes to
critical bugs (seg faults, crashing, etc) should not happen until the
actual release.
If we have a code freeze of any variety, than I would definitely say
that we should make a branch instead. Even with just a feature
freeze, I would suggest we branch the code at that point. The trunk
should not be our release candidate once we are in a feature freeze.
I have added my hoped for list of features to the feature list. I, of
course, reserve the right to change it up until the 6 May deadline ;)
I have also added a list for critical BUGS that should be fixed before
we consider the release stable. I initially populated the list based
on the short description, so some of the ones I put in the list
probably aren't really critical, and some BUGS that are critical
probably fell through the cracks. Please revise the list as
appropriate. Of course, if you fix a bug, it can be removed from the
list, although perhaps it should just be noted as FIXED. Note that I
labeled the list as bugs that should be "addressed". Some critical
bugs may not be fixable in the time frame of the release, but we
should ascertain that this is true for all the ones on the list that
we do not fix. Also I would suggest we use this list as the basis for
determining if a bug is critical if we are in code freeze. Newly
reported bugs would be compared to this list in terms of severity to
determine if changes should be made to fix them in the code-frozen
release candidate.
-Darth Fool
_______________________________________________
Wesnoth-dev mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-dev
