Tweet
There has been a further delay to the release of 4.0.2 and we felt an explanation to our customers for this delay is in order. Ultimately the release dates are almost always an estimate and we do our best based on the information and resources we have at the time of when we’ll be done with the current fixes. However, continuous improvement is something we constantly strive for and, as a result, we are currently re-evaluating our process to make it better. Even the best process will sometimes force us to make hard decisions between meeting schedules and meeting the product goals. We feel that in this case taking the time to get this right is more important than any artificial timeline. We are sorry for any inconvenience this causes, but we believe the end result will be much better and the time well spent.
The process we follow for a maintenance release is that we first prioritize outstanding bugs, then the Development team implements a number of fixes for these most critical ones. After this, we split the code off for testing and stabilization (which is why you see bugs fixed for 4.0.3 even though we haven't yet released 4.0.2). At this point only fixes deemed the most critical get merged into the prospective release – generally ones most important to customers – to fix things broken due to conflicts, or to complete previous fixes that weren't quite done correctly. Once we have the build stabilized, the QA team does a final pass through the release to check for problems.
So why a further delay for 4.0.2? To start with, we went over the estimate of fixes that we initially gave to QA -- more fixes means more time to test. We also identified a number of bugs fairly late in the process that we decided had to get fixed for 4.0.2, particularly those around RTL issues (right-to-left languages) and related to IE browser. We knew this would cause a delay, but we decided it was in the best interests of our customers to resolve these problems now rather than push them down to a future release.
Once we started digging into those bugs, we quickly found that fixing several of them would require very substantial changes to how we are handling RTL in IE6 and IE7. This required going through nearly all of the CSS in the system to find all the places that needed to be fixed. The trouble with changes like this is that it’s hard to estimate the time it will take to do the work. It also requires substantially more testing than we generally see with more focused fixes. Nonetheless, we felt what we could get done was of enough benefit to a significant number of customers that it was worth the risk to the schedule. So we went ahead with the fixes. As a consequence, our schedule became unpredictable and we've had to revise our release dates a couple of times as a result.
We hope you understand and we appreciate your patience while we make the new release the best we can before releasing it.
Kevin
The process we follow for a maintenance release is that we first prioritize outstanding bugs, then the Development team implements a number of fixes for these most critical ones. After this, we split the code off for testing and stabilization (which is why you see bugs fixed for 4.0.3 even though we haven't yet released 4.0.2). At this point only fixes deemed the most critical get merged into the prospective release – generally ones most important to customers – to fix things broken due to conflicts, or to complete previous fixes that weren't quite done correctly. Once we have the build stabilized, the QA team does a final pass through the release to check for problems.
So why a further delay for 4.0.2? To start with, we went over the estimate of fixes that we initially gave to QA -- more fixes means more time to test. We also identified a number of bugs fairly late in the process that we decided had to get fixed for 4.0.2, particularly those around RTL issues (right-to-left languages) and related to IE browser. We knew this would cause a delay, but we decided it was in the best interests of our customers to resolve these problems now rather than push them down to a future release.
Once we started digging into those bugs, we quickly found that fixing several of them would require very substantial changes to how we are handling RTL in IE6 and IE7. This required going through nearly all of the CSS in the system to find all the places that needed to be fixed. The trouble with changes like this is that it’s hard to estimate the time it will take to do the work. It also requires substantially more testing than we generally see with more focused fixes. Nonetheless, we felt what we could get done was of enough benefit to a significant number of customers that it was worth the risk to the schedule. So we went ahead with the fixes. As a consequence, our schedule became unpredictable and we've had to revise our release dates a couple of times as a result.
We hope you understand and we appreciate your patience while we make the new release the best we can before releasing it.
Kevin
