ToDo: Provide consistent package versions across build environments

[Olf0]

Currently the generated package version is not consistent, when either building by CI/CD (i.e. by the help of Coderus' Sailfish-SDK Docker-images) or at the SailfishOS-OBS: This might confuse users and RPM. Note that this only addresses the package version, not the release string, which is either taken from the RPM spec file or (unconditionally) auto-generated by the SailfishOS-OBS. (The final RPM file name is as always <package name>-<version>-<release>.<arch>.rpm.)

I developed a scheme which takes the peculiarities of the mandatory tar_git module at the SailfishOS-OBS into account for Storeman etc. This could be used or adapted for MeeCast. In any case this will require to strictly adhere to the format <release>/<version> for git-tags.

@vasvlad, if this required format for git-tags is O.K. for you, I will proceed researching this and ultimately adapt the GH-workflow configuration accordingly.

P.S.: This will require to adapt the release job in order to digest <release>/<version> as git-tag names and set the release title (free text field, only for GH release pages) to <version>-<release> (or if you insist to v<version>-<release>, but I prefer the simpler variant). Hence it will have to be triggered by (line 6) '*/*' as git-tags (or better / more concisely '*/[0-9]+.[0-9]+.[0-9]+' for SemVer).

[vasvlad]

Hi. Ok. I'm ready to try use your scheme. Please edit build.yml and show me the feature tag name for next release (for example for version - 1.11.7, release 1)

[Olf0]

Will do, but I have no idea when, because this task need some testing in an iterative approach in my clone ("fork") of MeeCast here at GitHub. I experienced that it is hard for me to get bigger changes in GH-workflow YAML files right on the first try. _{Hence, do not wait for that, a PR will come some day.}