> If you keep changing things like WML we will stay in beta time until middle of > next year... Please focus on fixing bugs in branches/1.12 so that we can > release the new series soon.
This is a good point but I think its only a small part of the story. There have been just as many problems with the GUI interface, with far more impact, than the WML changes. The real reason we are still in beta, IMO, is that there were huge changes to the project since the 1.10 release in many different departments, and little to no testing of the combined result until maybe December of this year. Beta 1 of 1.11.x was really closer to an alpha -- basic functionality was simply untested and missing, after major refactors had taken place, and just clicking around for a few minutes would reveal many bugs. Even after months in beta we still have struggled to get master into the "near-release" state demanded by beta. I think that when we we begin 1.13 beta, we should only do so after thorough internal testing, especially which ensures that the user interface is stable. If we make beta releases which are unusable because the users cannot click on units and similar issues (which have been a recurring theme!)... we will poison the well and be unable to get the testing assistance that we rely upon. It seems that right now, the timing of releases has mostly to do with, what is written in the changelogs, how long has it been since the last release, what are people's schedules like... and little to do with, what bugs are listed on the bug tracker, who has tested them recently, what are the results of independent testing of various areas of the project. It shouldn't be surprising then if the quality of releases is highly random and the target deadlines become hazy. If we are unwilling to commit to this kind of testing then IMO we should resign ourselves to the idea that, we will discover whatever bugs there are only whenever the person responsible finds them, and we will fix them whenever we get around to it. Especially, we should try never to have a repeat of 1.11.14, where we tag a release without doing basic sanity checks. Releases should go hand in hand with testing and review, otherwise they signify bureaucracy rather than progress. For example, one practice that we have right now is after tagging a release, we review the bugs on the bug tracker listed as "fixed" and "ready for test" and determine their status, closing as appropriate, so that we update our status almost in full just after any release. Maybe this process should happen *before* the targetted release date, so that the decision to actually make a release can be informed by the outcome. Best Regards, Chris Beck On Thu, May 29, 2014 at 10:13 AM, Nils Kneuper <crazy-ivano...@gmx.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi folks! > > I just wanted to remind you that branches/1.12 is under feature freeze. So > you > should not commit anything breaking the compatibility of WML unless there > is > absolutely no other way to fix an important bug. And when that is the case > you > should always link a bugtracker report to show this requirement. Shadowm > pointed out that in the last two release announcements changes in WML had > to > be mentioned which should no longer happen since we are in feature freeze. > > If you keep changing things like WML we will stay in beta time until > middle of > next year... Please focus on fixing bugs in branches/1.12 so that we can > release the new series soon. > > Cheers, > Nils Kneuper > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iEYEARECAAYFAlOHQHQACgkQfFda9thizwXbgQCgm1qmXtDYvx4VVM48Sk+mH6WP > ErUAoKJrzQCsNYTWzIF2qYTiidEny0ie > =MA2S > -----END PGP SIGNATURE----- > > _______________________________________________ > Wesnoth-dev mailing list > Wesnoth-dev@gna.org > https://mail.gna.org/listinfo/wesnoth-dev >
_______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
