-
Type: Improvement
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
5
-
Storage Engines 2018-12-31, Storage Engines 2019-01-14, Storage Engines 2019-01-28, Storage Engines 2019-02-11
The current compatibility test is pretty minimal, I'd like to see if we can do something better.
Suggestions:
- Instead of testing just the last two releases, could we build and test against the current major releases? I'm suggesting the most recent git tags for mongodb-3.2, mongodb-3.4 and mongodb-4.0, against the develop branch, and against each other, because as we release patches to those releases, we should continue to confirm their compatibility.
- I don't see any reason to configure test/format to configure and run against Berkeley DB, that's not the purpose of this test, so the configure script can be simplified.
- The configuration is pretty simplistic (rows=10000, ops=1000), and turns off things like reverse, (for build simplicity, but I think the expanded testing is worth a little complexity).
- The configuration doesn't test all of the access methods, it only tests one (randomly chosen). I'd like to see a more complex test of each of the access methods on every run.
- I don't think failures are being correctly archived, I think they're getting overwritten by each new test run.
- duplicates
-
WT-4492 Automate testing of versioned data format
- Closed