Currently when annotations a REST resource with the supported REST versions, we generally list each minor version separately, for example:
supportedOpenmrsVersions = {"1.9.*", "1.10.*", "1.11.*", "1.12.*", "2.0.*", "2.1.*", "2.2.*", "2.3.*", "2.4.*"}
This is problematic (or at least annoying) because each time we update to a new version of Core we need to find all the modules that define resources and add the new minor version.
For simple cases, is there any reason we don’t just do this:
supportedOpenmrsVersions = {"1.9.*", "1.10.*", "1.11.*", "1.12.*", "2.*"}
There’s some risk that that it doesn’t force us to explicitly consider/test if each resource is still relevant after we do an upgrade, but this seems like the lesser of the two evils… when we did the upgrade to 2.3.x we spend a fair chunk of time finding and reporting issues that were simply due to the supported versions not being updated.
Also, in the above example, suppose in 2.5.x we introduce a resource to supplant an existing one, I think we should be able to update it as follows:
Old resource:
supportedOpenmrsVersions = {"1.9.*", "1.10.*", "1.11.*", "1.12.*", "2.0.* - 2.4.*"}
New resource:
supportedOpenmrsVersions = {"2.5.* - 2.999.*"}
or it looks like for the new resource we could just do:
supportedOpenmrsVersions = {"2.5.0"}
… which means “2.5.0 and above” according to the docs here (although this isn’t intuitive to me)
Thoughts on following this convention going forward?
Take care, Mark