Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move to Autorelease 0.1.0 #66

Merged
merged 4 commits into from
Dec 6, 2019
Merged

Move to Autorelease 0.1.0 #66

merged 4 commits into from
Dec 6, 2019

Conversation

dwhswenson
Copy link
Owner

This PR updates to use the new version Autorelease (my framework for handling releases). I've already done releases with the new Autorelease for 2 other projects (Autorelease itself being one of them), so it should work.

The new version has a number of advantages. Here are a couple:

  • It uses the new Travis config import system, so all the fancy Travis stages are maintained in the Autorelease repository (note the simplification of the .travis.yml!)
  • It has better handling of versions (correct version number updates in developer installs)
  • Previously, if an error occurred after the deployment to testpypi, the only solution was to bump the version, leading to version skips. This is no longer the case -- you only need to bump the version if the error occurs after releasing on GitHub. (The trick to do this was a little fancy: I rewrite the setup.cfg to say that it is a development version, and increase the dev release number depending on what is already on testpypi. So testpypi only has dev versions.)

One major change is that all project-specific information is now in setup.cfg. The setup.py is project-independent, and vendored from Autorelease. The version.py is also vendored from Autorelease. When we want to upgrade to a newer version of Autorelease, we can copy the relevant files in (actually, by then Autorelease might have helper scripts for that, since that's a likely target for Autorelease 0.2.0).

@dwhswenson dwhswenson requested a review from sroet December 6, 2019 13:06
@dwhswenson
Copy link
Owner Author

@sroet : There's not much to do for reviewing this. All the code is vendored, so any changes to it should be made in the original location (in autorelease). Testing should also be there. Mainly asking for review so that you're aware of the change in structure around these parts of the project.

Copy link
Collaborator

@sroet sroet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One design question about copying over py2 specific code so close to EOL.
LGTM otherwise, feel free to merge

contact_map/version.py Show resolved Hide resolved
@dwhswenson
Copy link
Owner Author

AppVeyor is failing on ARCH=64 because for some reason it isn't copying the stuff from MANIFEST.in. This is weird, and will take some looking into.

@dwhswenson dwhswenson merged commit f3c770a into master Dec 6, 2019
@dwhswenson dwhswenson deleted the new_autorelease branch December 6, 2019 14:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants