(git) Respect build in version number

[thoscut]

Description

Currently the version check will not respect changes of the build number resulting in bugfix releases not updated automatically.

How Has this Been Tested?

Local test for latest release 2.47.0.2

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Migrated package (a package has been migrated from another repository)

Checklist:

• My code follows the code style of this repository.
• My change requires a change to documentation (this usually means the notes in the description of a package).
• I have updated the documentation accordingly (this usually means the notes in the description of a package).
• I have updated the package description and it is less than 4000 characters.
• All files are up to date with the latest Contributing Guidelines
• The added/modified package passed install/uninstall in the Chocolatey Test Environment(https://github.com/chocolatey-community/chocolatey-test-environment/). Note that we don't support the use of any other environment.
• The changes only affect a single package (not including meta package).

[AppVeyorBot]

✅ Package verification completed without issues. PR is now pending human review

[AdmiringWorm]

As mentioned in #2558 (comment), the .2 at the end of executable name is not the version number, but rather the revision.

This had been thought of before to include, but was not done as we wanted to have control over the 4th part of the version number to use for fix versions.

Even if we included this though, a name such as 2.47.windows.1 should equal to 2.47.0 which will not happen in this PR.

Also, since this would be considered a feature request, you need to follow the procedure for that. Features are not accepted directly, rather a discussion must be created before then.
Please read the CONTRIBUTING documentation.

I won't close this immediately, but I will mark it as a draft.

[thoscut]

Thank you for the clarification.

The benefit of reserving this part for manual fixes seems not as big, as we're discussing this change while the package, which could be updated automatically to include a fix many people are waiting for, is waiting to be updated manually.

I would vote for this PR and increasing the 4th part of the version manually if needed.
If the package, which should update automatically on new releases doesn't, it's a bug as it breaks the automation, not a feature.