Release often vs quality releases

[charlieg]

I think that the reality is that you have to find the right balance between frequent releases and quality releases.

This is why many FOSS projects adopt a concurrent stable/unstable development model. You have an infrequently updated but stable game which people can play with happily and updates are only bugfixes. Then you have a much more volatile development version with frequent releases and updates where the real meat can occur and will eventually turns into the next stable version. Y'know, the old evens (stable) and odds (unstable) numbering conventions.

Some projects go even further, having 3 different branches; stable, testing, and unstable.

[miyo]

I don't think we want to branch the code at the moment. We don't have too many active developers so I think we should focus on single goal... that is Wesnoth 1.0

- Miyo

[Dave]

Yes...if we had someone familiar with the code who was volunteering to be maintainer of the 'stable' version, then maybe yes. With the way things are, I don't think we can branch.

David

[gbu]

I agree with "guest". If it's not too onerous, I will report bugs, but
I think releasing buggy releases might reduce the number of people
who want to play the game. People who want the latest and
greatest can use CVS. With that said, frequent "bug fix" releases
would be *great*. I know there are a number of bugs in 0.6.1 that
have been fixed for a long time (well, mainly the "folks run off
randomly right after a save" bug), but no release yet. A new bug fix
release every time a bug gets fixed might be nice . Of course,
that also might be a pain in the behind, so I would understand
not wanting to do it. As for reporting bugs, wonder if it would be
a good idea to have a "bug report" feature in the software itself
early on...

[telex4]

I think that at the moment, simply releasing point releases that are announced on this forum during development, and releasing stable, playable releases that are announced to the world works fine. People who want to see occasional incremental improvements get them, and those who want to see every little change can do that too.

Once 1.0 is out it might make sense to concurrently release stable bugfix releases and 'unstable' development releases, the latter basically being what stable releases are now. That way Wesnoth can continue to promote a product that in every sense is "complete", whilst still releasing versions that need work in various but that are playable. It'd be rather like the release schedules for KDE or Freeciv.

[Insinuator]

Releases more often are better because it keeps peoples attention. If a release is only twice a year, say, all those who are not intrinsically involved in the project will lose interest. Even if there are bugs in the ones that are released, they will at least be a visual indication of progress. That way, interest is maintained and any newcomers see a rapidly advancing project(of course, development is at the same rate, it just seems faster). Think of the users pysche.

[RavenBlack]

Something like the current system seems sensible - having two binaries available, one known to be reasonably stable, one might-be-bugs version, the 'stable' release changing whenever one of the 'unstable' versions turns out to be relatively bugless. Frequency *and* quality, and the user picks which one they prefer.