Hello everyone. As we are in discussion mood already, what do you think about making bugfix releases? Is that something we should continue? Should we instead invest a bit more time into QA before each feature release (gather some testers from the community maybe?) and then stop caring about a release branch after we released the final version? Instead of releasing betas before the release, making the .0 release and then pushing bugfixes afterwards, we would only push alphas and betas (just a difference in name, to distinct the grades of stability) and a final release, but those prereleases would be more and come more often. After the final release we could fully concentrate on trunk and new features again. On the other hand doing bugfix releases we are able to fix smaller issues after a release via backports, and also by investing time into the diverged codebases of branches/* and trunk. It is mainly the choice between (rock?) stable x.y.z releases with more time to the next feature-release, or earlier feature releases with probably a few more bugs during the lifetime of the product. The later could be compensated if we'd find more of the bugs earlier, by having good testing (i.e.). Two-weekly prereleases, no matter of the current state, sounds like a good plan, with alphas starting right when the major features are merged.
This is an idea to prevent those long times between releases as we had them for the 2.1 series. I'd like to hear your opinions, ideas, insights. Maybe you've got a different/better idea how to prevent long times of silence between releases? --Devu
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
