Add changelog and changelog automation #3364
Conversation
|
The description of this PR should be in the docs included in the PR ;) |
|
We don't have a release manager doc yet, so I left this out. |
|
Also, this updates the changelog doc with a sample of 2.0 release. This can be updated when we actually release 2.0 |
tasks.py
Outdated
|
|
||
| This will stage a few updates for manual review and commit: | ||
|
|
||
| * Prepend the most recent PRs and issues that were closed to CHANGELOG.md. |
| config.read(setupcfg_path) | ||
| config.set('metadata', 'version', version) | ||
| with open(setupcfg_path, 'wb') as configfile: | ||
| config.write(configfile) |
There was a problem hiding this comment.
Isn't this the other way around?
configfile.write(config)
There was a problem hiding this comment.
Hah, that would make sense though. :)
The ConfigParser API is goofy:
https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.write
tasks.py
Outdated
|
|
||
| Do this after prepare task and manual cleanup/commit | ||
| """ | ||
| ctx.run('git checkout master && git tag {version}'.format(version=version)) |
There was a problem hiding this comment.
git push --tags or ...
Maybe after the prepare we need to stage and commit the changes. Then, release and after that push --tags but I think it should be written somewhere.
There was a problem hiding this comment.
Ah true, that would be a good addition.
I'm not yet sure of this workflow. I like the idea of performing one large step, but we might want to double check on things in between version update and commit/push. We'll figure out better ways in the future.
I'll add in the git tag push though, that should definitely live here.
There was a problem hiding this comment.
Yeah, the push maybe shouldn't be automatic be mentioned to the user to not forget to do it :)
First, update the version in our setup.cfg and changelog:
invoke prepare <version>
Then, hand edit and commit, added any release notes, etc. Tag manually or:
invoke release <version>
Finally, push up your changes.
This:
* Uses setup.cfg instead of setup.py
* Parses setup.cfg for version
* Updates setup.cfg on release prepare task
* Show our release version in our footer
* Uses invoke for task execution
* Uses a node library to hit GitHub and fetch the changelog
* Imports this into our existing changelog
First, update the version in our setup.cfg and changelog:
Then, hand edit and commit, added any release notes, etc. Tag manually or:
Finally, push up your changes.
This: