salt: --versions-report reports incorrect Salt point release

I build my own deb packages, which we host on our internal repository for distribution to machines on our network. This enables us to host patched builds (if required), and keep old releases around if we feel the need. It also means we are not necessarily reliant on connectivity to a remote 3rd party repository to bring up new machines. These are all important considerations for a production network. The build process is basically:

$ git fetch

# Checkout the appropriate tag (for 2016.3.3 in this example)
$ git checkout v2016.3.3
$ git checkout -b v2016.3.3-debian

# Fetch, verify and extract the debian packaging files.
$ mkdir ../debian
$ wget -P ../debian https://repo.saltstack.com/apt/debian/8/amd64/2016.3/salt_2016.3.3+ds-1.dsc
$ wget -P ../debian https://repo.saltstack.com/apt/debian/8/amd64/2016.3/salt_2016.3.3+ds-1.debian.tar.xz

# Checksum verification
$ gpg --verify ../debian/salt_2016.3.3+ds-1.dsc
$ grep -A2 '^Checksums-Sha256:' ../debian/salt_2016.3.3+ds-1.dsc | grep '.debian.tar' | sed 's/\s*\([^[:space:]]*\).*[[:space:]]\([^[:space:]]*\)$/\1  \2/' | { cd ../debian && sha256sum -c - ; }
$ tar Jxf ../debian/salt_2016.3.3+ds-1.debian.tar.xz

# Update the changelog
$ cp /path_to_old_changelog ./debian/changelog
$ debchange -v 0.16.3-1 -D stable 'New upstream release.'

# Commit the changes to our internal branch.
$ git add ./debian
$ git commit -m 'Add debian packaging support'

# Use a clean pbuilder environment. I know these aren't the typical
# branch names, but there is no practical difference.
$ DIST=jessie gbp buildpackage --git-ignore-branch --git-upstream-tree=v2016.3.3-debian

The packages are then uploaded to our repository for testing on staging, and generally everything works great… that is until you run --versions-report.

$ salt-call --versions-report | head -n 2
Salt Version:
           Salt: 2016.3.0

We’re using v2016.3.3, but the version bump was not included in the tag. Minor version releases never seem to get bumped. I assume you don’t intend for it to ignore the minor version number, so to address this we need to bump the version that --versions-report uses and tag that commit when performing releases in future.

This issue relates more to a process change than a coding change.