
Andrew Bennetts wrote:
"Martin v. Löwis" wrote: [...]
There is a certain prevention already that later maintenance fixes don't break the earlier ones: those fixes typically get checked into the trunk also, where the tests do exist. So the committer would find out even before the patch gets to the maintenance branch.
By this logic, the maintenance branch would need no tests at all, because they are all in trunk already!
No, this is not the logic. The tests in the maintenance branch have gone through alpha and beta releases, so end users have seen them already (at least, some of them). Of course, it might still be possible that there is an incorrect test in the released version; those can get fixed in later maintenance releases. So 2.6.0 will contain a lot of tests that have never been tested in a wide variety of systems. Some are incorrect, and get fixed in 2.6.1, and stay fixed afterwards. This is completely different from somebody introducing a new test in 2.6.4. It means that there are more failures in a maintenance release, not less as in the first case. Of course, it might be that a developer deliberately wants to see a certain test be run in the field, because there is a uncertainty whether the fix actually works. However, it is questionable whether such a fix would belong in the maintenance release. Regards, Martin