REST Resource supported versions

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?

@mseaton @burke @dkayiwa

Take care, Mark

1 Like

i would vote for it. :slightly_smiling_face:

@mogoodrich your suggestion is what i also have wanted all the time, considering the efforts we go through after each platform release, and in some cases we forget and get surprises.

I remember having raised the same before, to @darius, but he had a different opinion. @darius correct? :slightly_smiling_face:

Agreed, that makes sense to me.

I also encountered some issues. I think it’s a pretty thing to do.

+100. This has always been a head-scratcher for me. I don’t see why we don’t just adopt the same convention as we do with module requireVersion.

Especially since we are utilizing the module requireVersion methods to behind the scenes to implement this.

Unless someone weighs in with a strong dissent, I will use this model myself when going forward.

Take care, Mark

I ticketed this here to get us started:

I did leave this in Needs Design, however, as we determine exactly what approach we want. One downside of the approach I lay out in the ticket is that we will still need to manually modify all the resources when we upgrade to 3.0. An alternative to that would be just to change to a model like:

supportedOpenmrsVersions = {“1.9. 0”}

… which I think means “1.9.0 and above” (because it delegates to the “required verison” utility method that the module architect uses). However, I think this is non-intuitive as currently designed.

Also, of course, we will want to upgrade resources outside of the REST web services module, as these are the ones that are usually forgotten about and cause problems going forward.

Take care, Mark