Hi!
> I think that's overly cautious given the simplicity of the problem and the > fix, but it's your call. > > But even as a matter of principle, I don't know why you'd need a new RC in > one case, but not in the other. You'd have a release different from the Because revert means going back to old code, in which the problems are already known and which was tested, so while we don't get the fix for this bug, we can be reasonably sure there will be no new bugs introduced by the revert. Since we have a sad history of last-minute commits, I prefer to take the less risky pass. > last RC in both cases. It's true that the revert would only restore old > code, but, in general, you can't be sure the old code is still correct in > the context of the other changes since the last release (i.e. something > else could rely on the change. In principle). In principle, yes. But I have three options here: old code, new code and leave it as is. Of those three, old code with high probability does not make things any worse (it is quite improbable that we have some other change relying on the difference between old and new code - if there is, we'd have to revert that too, of course), new code is unknown, and leaving it as is means having known crash bug - which is worse than original bug that manifests itself only in some limited circumstances and does not lead to crash. I think the best way to go in this particular case is revert and have it in the next release. We're doing them each 4-6 weeks now so it's a small price to pay for more stable code I think. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
