Version: MAJOR.MINOR.PATCH for v2 and basic, bump rule and CI check #230

Goal

Move decoder from the 2.xx scheme (+0.01 per pull request) to MAJOR.MINOR.PATCH, make the legacy basic version canonical, and add a CI check that a code change comes with a new version.

Changes

• v2, android/app/build.gradle: versionName "2.17" → the next version in the new form (2.17.1 for a fix, 2.18.0 for a feature) in the pull request that next changes the app. versionCode stays a separate counter (+1 per version, now 42).
• Version numbers are no longer reserved for open pull requests (2.14 and 2.18 for fix: streams above 1080p in the single view (#166) #220): each pull request takes the next number by the rule when it is merged.
• basic, app/build.gradle: 1.07.1 has a leading zero; the canonical form is 1.7.1. Its next version is 1.7.2 (or 1.8.0). versionCode keeps growing as before.
• Release title (Release: "latest" titled "Decoder <version>", moving tag, SHA256SUMS, Telegram on a version change #229): Decoder 2.17.1 etc.; the notes line for basic shows 1.7.x.
• Docs: docs/testing.md:50-51 ("v2 is 2.xx", "+0.01", "basic keeps its 1.07.x line"): the rule below instead.
• CHANGELOG.md (Add CHANGELOG.md with the version history #228): old headings stay as they were released (2.00 … 2.17, 1.07, 1.07.1); the header says that later versions use MAJOR.MINOR.PATCH.

Version rule

Versions are MAJOR.MINOR.PATCH, numbers without leading zeros (the common rule of the OpenIPC repositories maintained together with vtesse, vectis, camex, cerberus and decoder):

• PATCH: fixes and small changes. MINOR: a new feature (option, format field, codec/protocol, platform). MAJOR: a large update or an incompatible change (arguments, config format, protocol, default behaviour), only when the maintainer decides.
• Every pull request that changes code or the build bumps the version as its last commit before the merge, together with its CHANGELOG.md section. Pull requests with only docs, CI, tests or images do not.
• The version lives in one place, android/app/build.gradle (versionName); the build, CI and the release read it from there, not from git tags.

CI check

A pull-request job that fails when code changed but the version did not (checkout with fetch-depth: 0):

ver() { sed -n 's/.*versionName "\(.*\)".*/\1/p' | head -1; }
base=origin/v2
changed=$(git diff --name-only "$base"...HEAD -- android)
old=$(git show "$base:android/app/build.gradle" | ver)
new=$(ver < android/app/build.gradle)
echo "$new" | grep -Eq '^(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)$' || { echo "::error::version $new is not MAJOR.MINOR.PATCH"; exit 1; }
if [ -n "$changed" ] && [ "$old" = "$new" ]; then
  echo "::error::code changed, version still $old; bump it (PATCH or MINOR) and add a CHANGELOG.md section:"
  echo "$changed"; exit 1
fi

Also check that the new version is greater than the old one (sort -V). Describe the rule where the project documents its releases (all three README files in one commit, or docs/).

On basic the same job with base=origin/basic, the paths app and build.gradle, and app/build.gradle.

Related: #228, #229, #220.