Salt: Salt 2016.11.5 Release on github pretends like it's 2016.11.0

Created on 20 Jun 2017 · 8Comments · Source: saltstack/salt

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

Bug Core P4 severity-medium

Source

farcaller

Most helpful comment

We upload them to pypi.

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

gtmanfred on 19 Jun 2018

👍2

All 8 comments

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

Ch3LL on 20 Jun 2017

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

gtmanfred on 22 Jun 2017

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.

s0undt3ch on 22 Jun 2017

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 😄

farcaller on 22 Jun 2017

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

Ch3LL on 11 Aug 2017

👍1

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.