CLI-995: acli --version no longer follows semver standard

[lmakarov]

Describe the bug

acli --version version output no longer follows semver and does not match the release version on GitHub.

This started with v2.8.1.

To Reproduce

$ export VERSION=2.8.0
$ curl -fsSL "https://github.com/acquia/cli/releases/download/${VERSION}/acli.phar" -o acli-${VERSION}
$ chmod +x ./acli-${VERSION}
$ ./acli-${VERSION} --version
Acquia CLI 2.8.0

$ export VERSION=2.8.1
$ curl -fsSL "https://github.com/acquia/cli/releases/download/${VERSION}/acli.phar" -o acli-${VERSION}
$ chmod +x ./acli-${VERSION}
$ ./acli-${VERSION} --version
Acquia CLI 2.8.1.0

Expected behavior

acli --version version output follows semver format and matched the release version on GitHub.

Desktop (please complete the following information):

• OS: Linux Debian 11

Additional context

This discrepancy may break automated tests (broke ours in docksal/cli).

[danepowell]

Does this actually hurt anything or is it just confusing?

GitHub, Symfony, and most other semver-based systems use a three-part version. But Composer internally uses a four-part version (with the trailing zero).

Since Acquia CLI has to play nicely with all of those ecosystems, the easiest solution is to adopt the leading zero, at least internally where we interact with Composer.

So we're between a rock and a hard place. To drop that trailing zero would require some deep hacking of either our Composer or Symfony integration. We did this until recently, when it became unsustainable (hence why the zero just started to appear).

[lmakarov]

Does this actually hurt anything or is it just confusing?

It's confusing, as the GitHub release version does not match the version the app reports.

Composer keeps things consistent (externally):

$ export VERSION=2.5.4
$ curl -fsSL "https://github.com/composer/composer/releases/download/${VERSION}/composer.phar" -o composer-${VERSION}
$ chmod +x ./composer-${VERSION}
$ ./composer-${VERSION} --version
Composer version 2.5.4 2023-02-15 13:10:06

So we're between a rock and a hard place. To drop that trailing zero would require some deep hacking of either our Composer or Symfony integration. We did this until recently, when it became unsustainable (hence why the zero just started to appear).

If you feel like it's not worth the hassle, so be it. We can hardcode that tailing zero in our tests.

Alternatively, adding a trailing zero to the release versions on GitHub would keep versions consistent.

[danepowell]

We can hardcode that tailing zero in our tests

Ah, I didn't expect people to be relying on version info like this or I'd have put it in the release notes. Sorry.

Let me see what we can do.