Updating Cinelerra-GG version numbering

Robert-André mentioning Cinelerra-GG and reminding me of the need to update it also brought to mind another issue I wanted to raise. Since I inherited the package, and in strict accordance with the Fedora Packaging Guidelines, the package versioning has stored snapshot details in the RPM Release field for each build, complete with snapshot date and git commit ID. That makes the NVR of the latest build this unwieldy mess: cinelerra-gg-5.1-58.20191231git3878a69 As you can see, we're up to release *fifty-eight* of "Cinelerra-GG version 5.1". That is, in part, because the current versioning doesn't accurately capture the upstream situation. Cinelerra-GG is a fork of a fork of a project, for all sorts of organizational and philosophical reasons, and version 5.1 is the upstream version it was forked from. The source project has moved on ("Cinelerra HV" is at version 7.2 currently), but in terms of the -GG fork the 5.1 version number is meaningless. There will likely never be a release of version 5.2, or 6.0, or whatever. They are equally unlikely to sync back up with any other fork's version numbering. This is even tacitly acknowledged by the -GG project. Since September 2018, Cinelerra-GG has officially been at "version Infinity"[1], and uses a monthly rolling-release model. A new version is published on the last day of each month. Since the 2019-08[-30] release, at my request[2], those monthly releases are published with a YYYY-MM tag in the project Git repo, satisfying (in my reading) all of the Fedora Packaging Guidelines requirements for those date tags to be considered upstream version numbers. As a result, rather than having the "cinelerra-gg-5.1" package continue on at the same version number until the end of time, receiving ever-increasing release numbers while we tag new releases as if they're snapshots (when they're not), I'd like to do the following: 1. Retain the "5.1" version number for consistency's sake, and since it's still used *internally *by the source code. (The folder name where the source lives inside the repo is "cinelerra-5.1".) 2. Incorporate the YYYY-MM tag format into the version number, by translating the dash to a period. The version numbering would follow the template 5.1.%{git_tag}, AKA 5.1.YYYY.MM. 3. Drop all of the git commit and date info from our the release numbering, at least for builds made from monthly tagged releases and not actual snapshots. As a result, rather than: cinelerra-gg-5.1-59.20200630gitXXXXXXX the next update would be: cinelerra-gg-5.1.2020.06-1 Does anyone have any objections, see any potential issues I've overlooked that would make this a bad idea, or simply feel I'd be violating the Packaging Guidelines with this change? Please raise any concerns now, and I'll alter my plans accordingly. Does the change require an exception to the standard package version numbering? In my view it's consistent with Fedora policy[3], but if I need to formally request an exception I can open a bugzilla ticket for that request. [1]: https://en.wikipedia.org/wiki/Cinelerra#Cinelerra-GG_Infinity [2]: https://www.cinelerra-gg.org/bugtracker/view.php?id=288 [3]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/