New release process?

Having just gone through the release process the first time myself I found that I wasn’t a huge fan of it.

I propose we do the following for releases, but I can be convinced otherwise:

1. Create a new branch, release-MAJOR.MINOR.PATCH.
2. Add a single commit to that branch that updates the version in urllib3/__init__.py and CHANGES.rst.
3. Send a PR to merge that branch into master. Someone must review.
4. Merge the PR and delete the HEAD branch.
5. Tag the squashed merge commit with MAJOR.MINOR.PATCH.
6. Let Travis upload the package to PyPI when built with tags.

This would mean removing the release branch.

/cc @urllib3/maintainers for #opinions

[sethmlarson]

Alright everyone I took a first stab at this by toying around with Travis a lot. Here’s the example repository I built: https://github.com/SethMichaelLarson/python-travis-deploy

The workflow for a release is:

• Any user creates a branch named release-x.x.x, commits CHANGES.rst and urllib3/__init__.py, and opens a PR to our master branch.
• Unit tests run as usual but integration tests also run against this commit. (This is where I’d add requests tests)
• Once this PR is approved it’ll be merged into master any maintainer can tag that commit and push the tagged commit.
• Travis will build the tag and run the PyPI deployment and draft a GitHub release for the tag of the same name.
• The GitHub release can be approved by any maintainer.

Next steps for me:

• Fork the urllib3 repository and integrate this into that fork and see how the deployment goes.
• Write up release procedure documentation for other maintainers and contributors.

What are other maintainers thoughts?

[theacodes]

That’s exactly what I’m proposing. I updated my comment to be a little more explicit on that. The release-MAJOR.MINOR.PATCH branch is just short-lived branch to initiate the Pull Request.