Week 17/2014: A new cycle
For the past couple of years we have been following a three month release cycle. However, while this has been good for moving forward, we haven't been allocating sufficient time for one crucial task: bug fixing. Instead, we have seen .1 and .2 patches regularly following stable releases as we've addressed the most important regressions and other high-profile bugs on an ad-hoc basis.
However, the bug tracker is full of known issues. We need to allocate time in our release cycle for addressing these in such as way that it doesn't interfere with the forward momentum of the unstable development phase.
We have agreed on a slightly revised release cycle with a length of four months. It is essentially the same as before, however we will reserve a one month period immediately preceding a stable release purely for bug fixing. This should then ensure that the first stable release is of high enough quality while allowing us to start reducing the total number of open bugs in the tracker. Adding a distinct development phase for bug fixing should also be beneficial because previously there has been a period of unfocused work following each stable release where we've been fixing the most criticial regressions while also trying to get started with new unstable work — both tasks have suffered due to the split focus.
The net effect hopefully should be that we can see real progress with closing bug reports while also having more time to focus our attention purely on the unstable work for the next stable release.
In practice, you can see the scheduled phases in the project's tracker. We will soon begin with the 1.15 unstable phase, and it will continue until mid-July.
However, the bug tracker is full of known issues. We need to allocate time in our release cycle for addressing these in such as way that it doesn't interfere with the forward momentum of the unstable development phase.
We have agreed on a slightly revised release cycle with a length of four months. It is essentially the same as before, however we will reserve a one month period immediately preceding a stable release purely for bug fixing. This should then ensure that the first stable release is of high enough quality while allowing us to start reducing the total number of open bugs in the tracker. Adding a distinct development phase for bug fixing should also be beneficial because previously there has been a period of unfocused work following each stable release where we've been fixing the most criticial regressions while also trying to get started with new unstable work — both tasks have suffered due to the split focus.
The net effect hopefully should be that we can see real progress with closing bug reports while also having more time to focus our attention purely on the unstable work for the next stable release.
In practice, you can see the scheduled phases in the project's tracker. We will soon begin with the 1.15 unstable phase, and it will continue until mid-July.
Comments