Use Autorelease for version/release management#883
Conversation
don't know why autorelease never caught that before, but the fix is actually much more readable than the original! changes have also be made upstream in autorelease
|
Seems to work! Of course, the real tests of whether it works will come when we do the next release (hopefully later this week). Note that I've also switched our nightly build from the external service nightli.es to Travis's built-in cron support (which didn't exist when we first started doing nightlies). On I'll leave this up for at least 24 hours for comment/review, and will merge on Wednesday 11 December if no objections. Note that much of the code added here ( |
This PR will move OPS over to the Autorelease workflow that I've been using with several other projects for the last few years. This will facilitate PyPI releases starting with 1.1.
One of the main ideas of Autorelease is that branches are either "release" or "development" — release branches should only include releases. We'll call our release branch
stable; our primary development branch ismaster.The automated release process in Autorelease 0.1 (which I cleaned up last week) is particularly useful. I'd been copying the relevant Travis configs into each project, but last month Travis made it possible to import configs from elsewhere. So now there's a single location for all the extra Travis stuff. The automated release process works like this:
stabledifferently than other branches. When you open a PR tostable, a test release is sent to testpypi; that test release is then redownloaded and the test suite is run, to ensure that everything that needed to be in the package is in the package.stable, the Travis-CI config imports in Autorelease will automatically cut a GitHub release, using the PR text as the release notes. A GitHub release creates a new tag in the repo; when Travis sees that new tag, Autorelease will again run tests (so that you have a pip-freeze type of record of the requirement version this should work with) and then deploys to PyPI.From a day-to-day perspective, the release process is as easy as updating the version number (removing the
.dev0) and making a PR against thestablebranch. Everything else is automatic. Once the release is out, make a branch off ofstable, bump the version, and merge intomaster(this approach minimizes likelihood of merge conflicts on the version line, although that's an easy conflict to resolve.)In addition, Autorelease provides a few scripts to vendor into our repo:
version.pythat keeps up-to-date versions for developer installs, while allowing a single location to store a "one true version"setup.pythat is independent of the project itself. All project information is stored insetup.cfg. Onlysetuptoolsis required for installation.I've already done Autorelease 0.1.0-based releases on two projects, and prepared a 3rd to use it the next time it releases. I think this is ready for OPS (although it may take a few commits to make OPS ready for it!)