Let me start by saying that I love the new version. However, the new version also came with the introduction of unpleasantly many new bugs. The problem being that for many of your average players, it is impossible to tell when the major ones of those bugs have been fixed while, hopefully, not too many new bugs have been introduced, making grabbing one of those nightly builds or compiling your own mostly a game of luck.
I would suggest releasing some sort of “patch” or a version that is considered to be (relatively speaking - I realize there will always be plenty of bugs at the current stage of development) stable after the release of a new major version.
This would, of course, require someone who is very well aware of the issues and which ones have been fixed. It might also require, if that is at all possible, to not include newer, untested features.
I am not sure if my suggestion is at all feasible or how much work it would require, but I am sure it would be much appreciated by a large portion of your player base. Thank you for your continued, dedicated work!
I agree that the way we handle releases could do with a bit of work. It seems like we’ve ironed out some of the procedural issues recently, but not all.
For 0.5, it seems like most of the really bad bug reports are related to Windows performance. That seems to be due to having relatively few people playing the dev versions in Windows. So, yeah, that’s certainly something we can work on.
I’ll also direct Kevin to this thread next time I see him, I know he’s thought about such things.
There are basically two approaches for this.
One is to fork before a release, and cherry-pick bugfixes to the release branch to try and stabilize it.
The other is to put a hold on new features during a stabilization phase.
Additionally as you suggest doing a major release followed by stabilization point releases can be helpful.
We’re discussing this, and will probably adopt some of these practices for the next release, though we’re still discussing which ones.