I'm pretty confident we can just automate the process you currently do. On 26 November 2016 at 05:40, Josh Smeaton <josh.smea...@gmail.com> wrote:
> I think automating as much of the release process is a fantastic idea. > Regarding bumping the release numbers, have you seen the bumpversion > project https://pypi.python.org/pypi/bumpversion? > > After some trial and error, I seem to have a configuration that works with > the existing version tuple in django/__init__.py. Bumping the release > number will change the VERSION tuple. The existing get_current_version will > continue to work as normal, as will the setup.py. You can experiment with > the tag/commit options and other options - the hard part is getting the > serialize and parse options correct. This configuration goes in the > existing setup.cfg. > > [bumpversion] > current_version = (1, 11, 0, 'alpha', 0) # you have to set this the first > time, then bumpversion updates it along with the VERSION tuple in > django/__init__.py > commit = False > tag = False > serialize = ({major}, {minor}, {patch}, {prerel}, {prerelnum}) > parse = \((?P<major>\d+),\s(?P<minor>\d+),\s(?P<patch>\d+),\s(?P< > prerel>\'alpha\'|\'beta\'|\'rc\'),\s(?P<prerelnum>\d+)\) > > [bumpversion:file:django/__init__.py] > > [bumpversion:part:prerel] > values = > 'alpha' > 'beta' > 'rc' > > And here's an example run: > > $ bumpversion patch --list > current_version=(1, 11, 0, 'alpha', 1) > new_version=(1, 11, 1, 'alpha', 0) > > $ bumpversion patch --list > current_version=(1, 11, 1, 'alpha', 0) > new_version=(1, 11, 2, 'alpha', 0) > > $ bumpversion minor --list > current_version=(1, 11, 2, 'alpha', 0) > new_version=(1, 12, 0, 'alpha', 0) > > $ bumpversion prerel --list > current_version=(1, 12, 0, 'alpha', 0) > new_version=(1, 12, 0, 'beta', 0) > > $ bumpversion prerel --list > current_version=(1, 12, 0, 'beta', 0) > new_version=(1, 12, 0, 'rc', 0) > > $ bumpversion prerelnum --list > current_version=(1, 12, 0, 'rc', 0) > new_version=(1, 12, 0, 'rc', 1) > > $ bumpversion major --list > current_version=(1, 12, 0, 'rc', 1) > new_version=(2, 0, 0, 'alpha', 0) > > With regards to Jenkins, you could have a release project with parameters > of BRANCH and VERSIONPART and whatever else was needed. The VERSIONPART > would feed into the bumpversion command. > > I think this way reduces backward compatibility concerns. > > On Saturday, 26 November 2016 06:49:54 UTC+11, Tim Graham wrote: >> >> After doing releases about once a month for a while, I'm thinking it >> would be nice if releasing Django could be a bit more automated. As far as >> I know, the process hasn't changed too much in 10 years, while the state of >> Python packaging has improved. >> >> Currently doing a release requires bumping the VERSION tuple in >> django/__init__.py [0], creating tarball/wheel and checksum files, asking >> someone in IRC to verify the checks look fine, and upload files to various >> locations [1]. My idea would be to use setuptools_scm [2] (that choice >> because this is the only tool I know about) to eliminate the need to >> bump/set a VERSION tuple and instead fetch the version information based on >> git tags. Something like (based on what I found in djanog-hosts [3]): >> >> __version__ = pkg_resources.get_distribution('django').version >> >> One issue I'm not sure how to deal with is how to provides >> backwards-compatibility for django.VERSION, the tuple format that looks >> something like: >> >> VERSION = (1, 11, 0, 'alpha', 0) >> >> I think removing or deprecating it would be quite disruptive for the >> community as I've seen lots of third-party apps that do checks like "if >> django.VERSION < (1, 9): ...", for example. I suspect it's possible to >> parse the version string to create something similar, but I wondered if >> anyone has experience with that. >> >> Finally, uploading to PyPI and djangoproject.com (release and checksum >> files) could be done automatically by Jenkins or something similar. >> >> Thanks for your comments, concerns, and suggestions. >> >> [0] https://github.com/django/django/blob/6252fd6314f66d2d303cc4 >> 7c791ffefd27169b42/django/__init__.py#L5 >> [1] https://docs.djangoproject.com/en/dev/internals/howto-releas >> e-django/#actually-rolling-the-release >> [2] https://github.com/pypa/setuptools_scm >> [3] https://github.com/jazzband/django-hosts/blob/0eae77b31927dd >> b0267943d6f9bcfc22f14706f2/django_hosts/__init__.py#L11 >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-developers/f36b9371-f292-47c5-a417- > c6557e5a2557%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/f36b9371-f292-47c5-a417-c6557e5a2557%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1HN8BXSx9Zj33z6T6uxLbvdwcVsXFrPoMGzyXpq265jrw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
