Salt 2016.11.5 Release on github pretends like it's 2016.11.0

[farcaller]

Description of Issue/Question

Downloading salt from GH releases results in an install that looks like 2016.11.0

Steps to Reproduce Issue

$ curl -LO https://github.com/saltstack/salt/archive/v2016.11.5.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   126    0   126    0     0    295      0 --:--:-- --:--:-- --:--:--   295
100 9143k    0 9143k    0     0  4144k      0 --:--:--  0:00:02 --:--:-- 9814k
$ tar xzf v2016.11.5.tar.gz
$ cd /salt-2016.11.5
$ python setup.py install --optimize=1
2016.11.0
running install
running build
running build_py
...
$ salt --versions-report
Salt Version:
           Salt: 2016.11.0

Dependency Versions:
           cffi: 1.10.0
       cherrypy: Not Installed
       dateutil: 2.6.0
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.9.6
        libgit2: 0.25.1
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.8
   mysql-python: Not Installed
      pycparser: 2.17
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: 0.25.0
         Python: 2.7.13 (default, Apr 20 2017, 12:13:37)
   python-gnupg: Not Installed
         PyYAML: 3.12
          PyZMQ: 16.0.2
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.5.1
            ZMQ: 4.2.2

System Versions:
           dist:
        machine: x86_64
        release: 4.10.0-22-generic
         system: Linux
        version: Not Installed

[Ch3LL]

I can replicate this behavior. Looks like we need to get this fixed. Thanks

[gtmanfred]

This is the expected behavior i believe

@s0undt3ch can you verify? I remember having a discussion about this before that pypi is the source of truth for the full version of salt.

Thanks,
Daniel

[s0undt3ch]

This undesirable and unavoidable. We can't disable GH downloads.

The only tarballs that report proper version are the ones SaltStack creates and uploads to pypi or those created from a repository checkout(python setup.py sdist).

The reason being that we gerenate the right version from git tags, and, for the tarballs we upload to pypi, we generate a _version module with the right version information, something that cannot be done for GH tarball downloads.

[farcaller]

I remember having a discussion about this before that pypi is the source of truth for the full version of salt.

That should be somewhere on GH page, preferably in bold, then 😄

[Ch3LL]

Okay going forward for the releases in github we will upload the tar ball from pypi and include this warning message:

WARNING: The tarball generated by GitHub will not have the correct version information when using a version not ending in .0 . Please use the tarball generated by SaltStack instead. See issue #41847 for more information.

You can see this in use here

[thatch45]

I wanted to add a comment here with regard to a conversation with the team at SUSE.
The version number used by Salt is automatically generated by the setup.py and stored in a file next to the version.py file called _version.py.
If a packager wishes to use the GitHub tarball as a package source then that is perfectly fine so long as they understand that they will need to create the _version.py file themselves since the setup.py will not be able to without the git tag and commit information.

[ncopa]

Please use the tarball generated by SaltStack instead. See issue #41847 for more information.

I was expecting to find an URL to the tarball generated by SaltStack here. Maybe add a link to where to find this SaltStack generated tarball?

[gtmanfred]

We upload them to pypi.

https://pypi.org/project/salt/