Week 39/2012: Keeping the ball rolling
Last week we were scrambling to fix the final serious issues for the stable version 1.9.9. Some of the issues got resolved while others were deemed too complex to fix in this time window. Now we set our sights again toward the future and decide what the next three months should be spent on.
Let's first do a brief post mortem of the 1.9.9 candidate phase. There were some exceptional circumstances in play this time as I spent a large portion of August moving to another city and this significantly reduced the time I had for Doomsday. Meanwhile, DaniJ was working on refactoring the old code for C++, fixing bugs, and optimizing the BSP builder and related map loading code.
The candidate phase officially started in the beginning of September. Based on past experience I felt that one full month is a suitable duration for the phase, so I had my mind set on a hard deadline for the stable release in the end of the month.
I'm quite happy with the balance of activities this time: while we managed to resolve a number of bugs, we also spent a fair portion of time on (long overdue) optimization. In the coming months I will try to incorporate optimization more into the normal development cycle so that overall engine performance will keep improving.
However, as the month went on, we learned that addressing all of the issues at hand was looking less and less likely. In particular, an important rendering optimization (GridMap) could not be finished in time, nor could we properly address a data caching bug related to multithreaded access. These are not new regressions, though; we have only now started looking into them in more detail, and felt that rushing fixes into the stable 1.9.9 release would not produce the best possible end result.
This is a good example of what it means to do rigid time-based releases instead of trying to nail down a specific set of features/fixes. As the time window for a release closes, we just have to accept that the unfinished work is not suitable for release yet and must wait for the next release window. The only acceptable reason for extending the release window are serious regressions, i.e., new bugs that were introduced in recent changes after the latest stable release.
I ran the stable 1.9.9 build 638 late on Saturday evening (EET).
As the weight of the candidate phase has now been lifted, the team is again freed to reconsider to roadmap ahead and refocus our efforts. Here are a few thoughts about the future:
Let's first do a brief post mortem of the 1.9.9 candidate phase. There were some exceptional circumstances in play this time as I spent a large portion of August moving to another city and this significantly reduced the time I had for Doomsday. Meanwhile, DaniJ was working on refactoring the old code for C++, fixing bugs, and optimizing the BSP builder and related map loading code.
The candidate phase officially started in the beginning of September. Based on past experience I felt that one full month is a suitable duration for the phase, so I had my mind set on a hard deadline for the stable release in the end of the month.
I'm quite happy with the balance of activities this time: while we managed to resolve a number of bugs, we also spent a fair portion of time on (long overdue) optimization. In the coming months I will try to incorporate optimization more into the normal development cycle so that overall engine performance will keep improving.
However, as the month went on, we learned that addressing all of the issues at hand was looking less and less likely. In particular, an important rendering optimization (GridMap) could not be finished in time, nor could we properly address a data caching bug related to multithreaded access. These are not new regressions, though; we have only now started looking into them in more detail, and felt that rushing fixes into the stable 1.9.9 release would not produce the best possible end result.
This is a good example of what it means to do rigid time-based releases instead of trying to nail down a specific set of features/fixes. As the time window for a release closes, we just have to accept that the unfinished work is not suitable for release yet and must wait for the next release window. The only acceptable reason for extending the release window are serious regressions, i.e., new bugs that were introduced in recent changes after the latest stable release.
I ran the stable 1.9.9 build 638 late on Saturday evening (EET).
As the weight of the candidate phase has now been lifted, the team is again freed to reconsider to roadmap ahead and refocus our efforts. Here are a few thoughts about the future:
- We intend to finish the GridMap optimization and the caching bug for a stable patch release in the coming weeks. In practice, these will first be introduced and tested in the unstable builds, after which the (relevant) changes are merged to the stable 1.9.9 branch for the patch.
- As time goes on, operating systems evolve and old versions fall into disuse. To ease our development and testing efforts, we are considering dropping support for Windows XP, OS X 10.4, and OS X 10.5 in the future (1.9.10 or 1.9.11). We will write more about this when the final decision has been made.
- 1.9.10 has been scheduled for the end of the year. Three months is plenty of time to begin work on some major roadmap items such as Doomsday Script and the foundations for the new renderer. I would not expect major graphics improvements in 1.9.10 yet, though, although some of the low-level subsystems may be replaced. However, looking at the current state of the Roadmap for 1.9.10, it is looking a tad long. It is likely that some of the currently listed items will be reassigned to a later release.