Presumably, uploaders will be able to retroactively specify the minimum compatible Vassal version, once that is implemented in the front- and back-end.
In the mean time, I’ve added a suggestion to How to upload modules to the Game Library to specify the minimum required Vassal version (as well as what currently isn’t possible).
I think the best compromise is the dual approach I suggested above.
-
An uploader or owner may specify the minimum compatible Vassal release, preferably chosen from a drop-down menu, so that uploaders or owners cannot give bogus information.
-
If the uploader does not specify anything, then the Vassal release used to make the module, rounded down to the least patch release will be used.
What I mean by rounded down to the least patch release if for example, if a module was made with Vassal release
3.7.15, then the least patch release will be3.7.0. I think that’s a reasonable assumption, because patch releases should not introduce incompatible changes, according to semantic versioning.
Ideally, and owner of a project should be able to edit the minimum required Vassal release, even after upload.
One could consider also adding a maximum compatible Vassal release, since sometimes modules contains custom code, developed against older Vassal releases, that is not compatible with newer Vassal releases. However, I think that’s a complication that will not be generally useful, so maybe not worth the effort.
Likewise, one could consider adding a minimum (and possibly also maximum) required module release for saves, logs, and extensions, which could be set in the same way as the module requirements are set (either by choice, or automatically from the meta data in the file - e.g., a .vsav made with _modul_e release 1.2.3 has a compatibility range of 1.2.0 to 2.0.0 because incompatible changes to the module should increment the major release number). Clearly, it is a complication, but could be useful in more cases.
Yours,
Christian