David W. Van Couvering wrote: > I think the same could be done for code coverage regressions. If a new > chunk of code is checked in and the numbers drop way way down for a > given module, I think that is cause for concern and a committer could > reasonably insist that the feature is not sufficiently tested and back > out the change, or at least block any future checkins in that area until > enough tests are provided.
So we could have applied this rule to JDBC 4.0 checkins. JDBC 4.0 code was checked in, the code coverage numbers decreased and could not increase until the tests could run under JDBC 4.0. In this case requiring the JDBC 4.0 changes be backed out until all the tests ran under JBDC 4.0 seems too drastic. Goes against the model of incremental development. Dan.
