Build: Version comes from git tag, ChangeLog, Jamulus.pro

[hoffie]

My concern is get_build_version() uses a different value. The tag, Jamulus.pro and ChangeLog could all have different versions.

Given we have three sources for the version, we really need automation to make sure they're aligned, at least: i.e. error out if things look wrong. But I agree, that's not in scope here. For that, it sounds like (and I don't fully understand how this works):

• If the tag is set, we should use that to determine build type and version and that source should overrule others.
• ChangeLog and Jamulus.pro "target" versions should match - and, if set, match the tag build type and version.
• If the tag wasn't set, build type and version can then come from ChangeLog and Jamulus.pro, as needed.

Originally posted by @pljones in https://github.com/jamulussoftware/jamulus/pull/2656#discussion_r901061485

[ann0see]

Just a note, we shouldn't extract the version from ChangeLog. We could automatically extract the version from the tag and put it into Jamulus.pro

[pljones]

Just a note, we shouldn't extract the version from ChangeLog. We could automatically extract the version from the tag and put it into Jamulus.pro

I think the problem is that there might not be a useful tag when someone triggers the autobuild -- and it still has to work. So it has to get a version from somewhere. To me, Jamulus.pro should actually be the overruling version (regardless of tag). That must exist for a run to work. ChangeLog doesn't have to exist for qmake && make to work but Jamulus.pro must.

(So yes, I said let the tag overrule -- but I'm not fixated on that...)

[ann0see]

I think we should write a release script doing the tagging,...

[pljones]

I don't think we know enough about what the solution will look like to target a release. Dropping the milestone and moving to Triage.

On another note:

I think we should write a release script doing the tagging,...

It could for the way we do it now by hand. But it depends what we want.