Commit Graph

5 Commits

Author SHA1 Message Date
Robin Jarry 4f71027fcd enhance version management
When making an official release of scapy, one must:

* Modify the hardcoded version in setup.py and scapy/config.py
* Create a commit with this change
* Create a git tag with the same version
* Run ./setup.py sdist register upload
* Modify the hardcoded version in setup.py and scapy/config.py again to
  append '-dev'.
* Create another commit with the modified version.
* Push the 3 commits and the tag.

Not only this is tedious but it is also error prone.

Add utility functions in scapy/__init__.py to determine current version.

If git is available (thus running from a git clone), use "git describe" to
get the current version. Write the version for future reference to a
text file (scapy/VERSION).

If git is not available (running from an installed scapy package) read
the version from the scapy/VERSION file.

This changes the release process as follows:

* Create a git tag on the commit where you want to release
* Run ./setup.py sdist register upload
* Push the tag

This allows to have a single place where the version is managed: git.

Note: change the development versions to X.Y.Z.devN where N is the
number of commits after the last tag. This complies to PEP 440
https://www.python.org/dev/peps/pep-0440/#developmental-releases

Signed-off-by: Robin Jarry <robin.jarry@6wind.com>
2016-09-05 13:38:41 +02:00
Phil 57df4b7ef8 Added all files in bin/ to MANIFEST.in so that .bat are not forgotten in source archive 2010-04-07 14:13:47 +02:00
Phil 8ae4ed72a1 Updated MANIFEST.in to include test and the whole doc 2009-02-05 17:04:54 +01:00
Phil 6fdbebd1a8 Added a run_scapy script at the package's root to run scapy without install 2008-09-12 14:02:13 +02:00
Phil 7844c74e20 Added MANIFEST.in 2008-08-25 19:34:43 +02:00