The spring months have been a little crazy with various Real Life time sinks preventing me from delving too deep into fun coding. Consequently, there has been little to no progress with the tasks on the roadmap, such as the multiplayer improvements for version 2.1. Given that several months have passed, it will be challenging to find motivation to restart this work. I am tempted to make some changes to the roadmap to get things rolling along again.
I have managed to steal away some time to explore an exciting new direction for the renderer, though. The basic gist of this effort is to completely revise how the game world is drawn, bringing it up to par with the recently redone 3D model renderer.
Continue reading Status update
Last week I was fixing some regressions and tweaking the UI. Audio plugin selection GUI was brought back as part of the Audio Settings dialog. Continue reading Audio plugin selection
I took a good look at the project roadmap in the Tracker and decided it was time to do some spring cleaning.
I’ve now updated the plan for the 2.x releases so that each version has a specific focus. For instance, the 2.0 release will focus on the Home UI and basic package management, and the 2.1 release will focus on multiplayer improvements.
While the roadmap is just a plan and plans may always change, defining a clear focus area for each version will help in pushing things forward. Not doing this would mean that each release has the risk of ballooning feature creep and features would likely not be fully baked.
Another topical issue to note is that due to the autobuilder upgrade, the stable 1.15 builds have been suspended until the stable build environment is updated to work with the new builder setup. However, I’m placing my focus on finishing features for the 2.0 stable release, so I don’t expect many fixes for 1.15 in the near future.
There are two popular ways to manage software releases: feature driven or timeboxed. In a feature driven project, each version commits to a predetermined set of changes and the release is done when everything has been finished. In a timeboxed project, releases are done based on calendar dates without committing to any particular set of features. The latter method is used for example by modern web browsers and Ubuntu.
We more or less followed the timebox method during stable releases 1.9.10–1.14, having a roughly three month release cycle for each version. However, during the 1.15 unstable builds the schedule was first extended and then continually delayed. It eventually became clear that we had abandoned the notion of timeboxing completely.
Continue reading When it’s done