sphinxcontrib-spelling 4.3.0

What’s new in 4.3.0? Logging: use warning() instead of its deprecated alias (contributed by Sergey Kolosov) Support additional contractions (contributed by David Baumgold) require sphinx >= 2.0.0 declare support for python 3.6

sphinxcontrib.datatemplates 0.4.0

What’s new in 0.4.0? deprecate the datatemplate directive in favor of the directives in the domain Wrap directives in minimal domain (contributed by Jan Brohl) Add directive “datatemplate” for backwards compat (contributed by Jan Brohl) Split datatemplate directive by file type (contributed by Jan Brohl) Ignore venv, vscode settings (contributed by Jan Brohl) add option for encoding (contributed by Jan Brohl) Upgrade Note This release deprecates the “datatemplate” directive in favor of source-specific variants in the datatemplate domain.

sphinxcontrib.datatemplates 0.3.0

What’s new in 0.3.0? Add dialect support, better dotumentation (contributed by Jan Brohl) Use yaml.safe_load (contributed by Jan Brohl) Add XML support (contributed by Jan Brohl) Add CSV support (contributed by Jan Brohl)

imapautofiler 1.8.0

What’s new in 1.8.0? use yaml safe loader drop python 3.5 and add 3.7 support perform substring matches without regard to case

sphinxcontrib.datatemplates 0.2.0

What’s new in 0.2.0? Use sphinx.util.logging for logging calls (contributed by Sean McGinnis) optionally exec the conf.py file and pass settings to the template make test-template support python 2 and 3 update to python 3.5 add license file Add links to repo and docs from README and docs frontpage (contributed by Christoph Deil) add a command line tool to make testing templates easier

sphinxcontrib-spelling 4.2.1

What’s new in 4.2.1? fix remaining logging issue (contributed by Timotheus Kampik) Remove usage of deprecated logging API (contributed by Tim Graham)

Planting Acorns

This post is based on the closing keynote I gave for PyTennessee in February 2018, where I talked about how the governance of an open source project impacts the health of the project, and some lessons we learned in building the OpenStack community that can be applied to other projects. The presentation was not recorded.

reno: A new way to manage release notes - Europython 2018

Yesterday I delivered a presentation at EuroPython describing how reno works and why we created it for OpenStack. reno is a tool for managing release notes in projects that support multiple branches of development, and releases, simultaneously. It solves the problem of managing release notes within patches that fix bugs, and makes it easier to cherry-pick changes between branches (allowing backports or forward ports). This talk will cover the requirements, and constraints, that led us to design and build reno.