![[de]](/mwf/flags/de.png "Germany")
For the RWD Clonk titles, we used to have a set of test conditions (a bit misleadingly called unit tests by matthes) of things that used to break often but had to work for the release. They were in the bug tracker, marked as open before every release and had to be resolved on the release candidate of any release.Those were step-by-step instructions including stuff like playing through the tutorials, creating+resuming a savegame, (runtime join?), creating a player, etc. Maybe we can assemble such a list of tests for OC as well to make sure we don't get any last-minute-bugs into a release?
Since you got not reply yet on the forum: I think this is a good idea. The only problem I see with this is that they litter the normal bugtracker which is already more than full of reports ATM. It would be nice if it is possible to file them under one meta-bug and otherwise don't show them at all.And this is my only concern right now: The bugtracker is more than full of already assigned bugs but the progress is very slow. Some (assigned!) issues have not been touched at all during the last weeks (e.g. melee weapons) or even months. I don't want that we choke in issue reports ;-).
Otherwise, your suggestion is a good idea. Altough, perhaps to solve this list should not be required for the first launch. By now, I have the opinion that the first release should be released as a "beta"/work in progress (see test home page) because otherwise we will never get to release something, IMO. There is always something which could or should be included/fixed/improved/added. This list could then be looked at during the "beta" phase/after we announced the public download.
I'm a bit uncomfortable with a release that contains known bugs. The first release is potentially downloaded by many people who try out OpenClonk to get a first impression; and if that impression is spoiled, they won't ever try it again.It doesn't matter if the game is still small and some content is missing. But showstopper bugs like the ones tested in release tests really should be fixed - or functionality disabled for a release. E.g., if savegames and runtime join cause trouble, just turn them off.
I agree with Sven. We don't need to track this in the bugtracker necessarily but we should make sure the release halfway works. For CR we used a different section in the bugtracker so that the "Release tests" are not shown together with the other bugs. There was a dropdown box in the upper right corner to switch sections. If you still don't like the bugtracker then we can also do it in the Wiki or even in the forums.
As for the problem that always something can be "included/fixed/improved/added" we should set a feature freeze date after which no new features are added to neither engine nor content and we concentrate on bugfixing (new features could still go in a separate branch maybe).
As for the problem that always something can be "included/fixed/improved/added" we should set a feature freeze date after which no new features are added to neither engine nor content and we concentrate on bugfixing (new features could still go in a separate branch maybe).
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
