Closed ZuluPro closed 8 years ago
:+1:
Perhaps use a Makefile inspired by the way that cookiecutter-pypackage configures things?
The best way to implement these conventions in our project that I know of, would be a Makefile.
So we'd have make release version=1.2.3
release: clean
git tag $(version)
git push --tags
python setup.py sdist upload --sign
(should use twine of course, but I haven't made the switch)
Don't forget to update the dbbackup/init.py file, or maybe remove the variables in there if they are no longer needed.
Yup, good point, no idea how to script it, though.
One idea would be to do like django's get_version
and always keep a date-based version in dbbackup/__init__.py
Then only when releasing, making an amendment to the third version component that isn't actually committed.
Here's how twine is used: https://github.com/Bernardo-MG/cookiecutter-python-library/tree/master/%7B%7Bcookiecutter.repo_name%7D%7D
It should be a great thing to track version number in git tags, like in Django project.
I think a little script which register to PyPi, create tag and push it will do the job. (Don't use
setup.py register
, it doesn't use HTTPS and send your credentials, there's twine for this)Small question in passing: I saw last version is 2.0.5 alpha: https://pypi.python.org/pypi/django-dbbackup/2.0.5a We do not have history before Bitbucket import, do you really think this version number is appropriate ?