Release Management

[stefanv]

Common solution for changelog / release notes.

Henry Schreiner mentioned pybind11 pulls changelog entries from GH PR description. So does @choldgraf's tool. NumPy uses Towncrier. SciPy uses a wiki.

[choldgraf]

It's not my tool! It is contributed to by many folks in the jupyter and ExecutableBooks ecosystems!

https://github.com/executablebooks/github-activity

[pllim]

astropy and sunpy both use towncrier and https://github.com/OpenAstronomy/sphinx-changelog .

However, smaller repos in Astropy do not, as the cost of setting up towncrier and taking care of the fragments is too high for low-traffic packages.

[bsipocz]

astroquery, and other libraries I maintain use a CHANGELOG file, as towncrier would be a big gun for these, but also relying on auto-generating from PR titles, etc is not a solution (we need more structure in the changelog to distinguish modules, and PRs are not really well disciplined anyway). For QA, before cutting a release, I run a bunch of bash scripts to double check all PRs either have their changelog or have a label that they don't need one.

[lwasser]

woah - @choldgraf i'm curious about that tool. I also was planning on writing some tooling around capturing issue activity for our review process. number of issues a month, etc. i wonder if that github tool might be helpful there before i start building that?

[tylerjereddy]

SciPy has been fairly happy with the low-tech wiki approach to avoid merge conflicts for the most part. Well, except for the ~3 days before branching where I have to reformat stuff and expand + select highlights. But 2x/year hasn't been enough pain to justify something more complicated.

There are some pretty silly things that happen, like when I paste relnotes to GitHub and to emails I physically go through the notes and extend or retract subtitle underlines --------- and/or convert to/from =====, etc. There's a bit of a mess with restructured text vs. WiKi vs. GitHub markdown vs. whatever ends up in emails. I'm not sure how much engineering effort it is really worth though.

[tylerjereddy]

Also, uploading wheels to GitHub release page web interface can be pretty painful on standard North American residential internet (say 5 MiB/s upload)--I'd say I get ~20 % failure rate, come back to the computer, and end up purging out or having to do a checklist of which uploads got corrupted... PyPI uploads via command line are more robust to failure, and failure seems to happen less often, even with slow upload. Another solution is to do release at work of course, when possible...