...

If the version of the project file is older than the oldest legacy hbm this version is not supported and a message should be shown. For example you have a db 0.4 but mappings only support back to 0.6. So 0.4 is no longer supported and the load cannot continue. So in a flowchart :

So how does this affect plugin development?

If you release a version which you want to support you should include a test reading a project file of that version. So when you release your plugin 1.5 you should write a test called ReadVersion1.5 in your plugin that reads a project that covers all possible mappings you have in your plugin. You should check you get everything back from the project as you expect it. The dsproj file is checked into svn and the test should work as nothing changed yet. All is well....

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.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 this:

1 If you release write a test that reads in a project created with that release.

2 If the test of 1) breaks add version specific mappings.