Use ReleaseVersion instead of no-longer-populated vcsTag

[labkey-jeckels]

Rationale

vcsTag is no longer populated. Use ReleaseVersion instead for mothership reporting to track maintenance release versions.

Related PRs

• Update gradle plugins version to eliminate VcsTag in module.xml file server#1324

Changes

• Swap the source of the vcsTag module metadata submitted to mothership
• Remove defunct vcsTag from Module interface

Tasks 📍

• Manual Testing

[labkey-susanh]

I guess if you're removing all the getters for the VcsTag property I can go ahead and remove its population from the gradle plugins as well.

[labkey-jeckels]

I guess if you're removing all the getters for the VcsTag property I can go ahead and remove its population from the gradle plugins as well.

I had to restore the setter because Spring was displeased having a vcsTag value in the XML without a matching field on the module class. Feel free to delete it. Or we can use the same FB to do it all at once.

[labkey-susanh]

I guess if you're removing all the getters for the VcsTag property I can go ahead and remove its population from the gradle plugins as well.

I had to restore the setter because Spring was displeased having a vcsTag value in the XML without a matching field on the module class. Feel free to delete it. Or we can use the same FB to do it all at once.

Removed setter again after creating server branch with new gradle plugins version.

[labkey-susanh]

I have verified that the vcsTag value shows up in the mothership data:

"Premium": {
"simpleMetricCounts": {
"controllerHits": {
"premium": 37
}
},
"assayExclusionCount": 0,
"qcTrendReportCount": 0,
"buildInfo": {
"vcsTag": "26.3-SNAPSHOT",
"buildTime": "Apr 3, 2026, 6:32:04 AM",
"moduleClass": "org.labkey.premium.PremiumModule",
"vcsBranch": "Unknown",
"buildNumber": "Unknown",
"vcsUrl": "Unknown",
"version": "26.000",
"vcsRevision": "Unknown"
},
...
}

and is not shown in the module info:

[labkey-jeckels]

I guess if you're removing all the getters for the VcsTag property I can go ahead and remove its population from the gradle plugins as well.

I had to restore the setter because Spring was displeased having a vcsTag value in the XML without a matching field on the module class. Feel free to delete it. Or we can use the same FB to do it all at once.

Removed setter again after creating server branch with new gradle plugins version.

Is there any value in keeping the setter around for pre-built modules with an old XML that might be deployed as-is? Or maybe we just add a release note and add the exception to our troubleshooting page?

[labkey-susanh]

I guess if you're removing all the getters for the VcsTag property I can go ahead and remove its population from the gradle plugins as well.

I had to restore the setter because Spring was displeased having a vcsTag value in the XML without a matching field on the module class. Feel free to delete it. Or we can use the same FB to do it all at once.

Removed setter again after creating server branch with new gradle plugins version.

Is there any value in keeping the setter around for pre-built modules with an old XML that might be deployed as-is? Or maybe we just add a release note and add the exception to our troubleshooting page?

If we don't remove it now, we'll want to try to remember to remove it later, but it is probably better to not have a breaking change for a maintenance release.

[labkey-jeckels]

I guess if you're removing all the getters for the VcsTag property I can go ahead and remove its population from the gradle plugins as well.

I had to restore the setter because Spring was displeased having a vcsTag value in the XML without a matching field on the module class. Feel free to delete it. Or we can use the same FB to do it all at once.

Removed setter again after creating server branch with new gradle plugins version.

Is there any value in keeping the setter around for pre-built modules with an old XML that might be deployed as-is? Or maybe we just add a release note and add the exception to our troubleshooting page?

If we don't remove it now, we'll want to try to remember to remove it later, but it is probably better to not have a breaking change for a maintenance release.

Great point. Let's restore in this PR and yank it from develop once this is merged forward. I pushed a commit to bring it back temporarily.

[labkey-jeckels]

I logged an issue https://github.com/LabKey/internal-issues/issues/1039