In Configuration for CO where it says “COmanage Registry v4.1.0” it would be nice if this would indicate the RCn release.

From slack https://internet2.slack.com/archives/CBRDZ70NN/p1673377358178329
14:02
Michael Gettes 
In Configuration for CO where it says “COmanage Registry v4.1.0” it would be nice if this would indicate the RCn release.
!https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-small/1f44d@2x.png!1
 
16:38
Benn Oshrin 
We’ll have to think about that a bit. The version label rendered on the configuration page is based on the version label in the code directory, which in turn is used for things like upgrade calculation. The Release Candidates aren’t, in this sense, actually versions. In theory the only difference between RC2 and Final could be dropping the “RC2” from the packaging label. (ie: They could be tags to the same git commit.)

16:42
Michael Gettes 
While I understand this is how you have done things… this is not how most products work.  The version of the product is seen throughout and isn’t just a packaging label.  It’s important to get an indicator of what release (version/minor version/etc…) we are actually running and it matches the packaging.  Even grouper is doing this now.  I know you said you will think about it… just trying to help more with the reasoning behind it.
Today
----New
10:53
Benn Oshrin 
Since we started doing release candidates after the embedded version processing code was written, it’s a non-trivial change to introduce rc labels. Not saying we shouldn’t do it, just that it isn’t easy. Also, if we’re going to muck around with this we probably want to think about how to bubble up the commit label for when deploying a specific commit - there’s no support for that at all right now, and we’d need a solution that work both with (easier) and without (harder) containers. Minimally, can you open a JIRA for this? It’ll probably need some discussion within the dev group.