...
- Take the first mapping file with a version equal or more recent than the persisted version.
Note Revision / build version numbers are ignored; 3.0.5 is treated as 3.0. The idea behind this is that file format changes should only occur in major or minor versions.
More elaborate, in a chart:
...
After a while you want to refactor your class A. You also change the mapping A.hbm.xml. But the test ReadVersion1_5 you wrote on release now fails because reading the old db with the new a.hbm.xml does not work! What to do? You can chose not to refactor A and do something else OR you could add a A.hbm.1.5.hbm.xml mapping that converts the old db to the new object. Once you check in that new mapping file *ReadVersion1.5 should use that specific file (instead of A.hbm.xml) and the test should pass again.
So for a plugin it boils down to 4 points:
*1 Write a ignored (not run on BS) test that can create a dsproj file with all persistent objects you have in your plugin. You create a 'representative' project here. Update this test as your plugin evolves and add the category **\the category [BackwardCompatibility\]*unmigrated-wiki-markup Wiki Markup
*2 If you have a release with file-format changes run test 1) and copy the result to the release version. Write a test that reads in that project file and add the category \the category [BackwardCompatibility\]*
For example if you release 1.1 you should run the test of 1) and copy the result to project1_1.dsproj + data. Check in this project and write a test ReadVersion1_1 that reads this project. You will never change this checked in project again.
...