These are chat archives for cherrypy/cherrypy

15th
Aug 2018
Sviatoslav Sydorenko
@webknjaz
Aug 15 2018 09:19
@jaraco let's have a rule of adding sources of changes to changelog: if an issue is closed by PR or commit our sphinx config understands :pr: and :commit: for the current repo. Also there's helpers to refer Cheroot from CherryPy :cr-pr: and cr-issue. And there's additional helper :gh: for arbitrary GitHub slug.
Sviatoslav Sydorenko
@webknjaz
Aug 15 2018 09:24
@jaraco I've started using practice of submitting post-releases with minor metadata or changelog changes, which don't affect actual code. I think, docs changes can go there as well (if needed).
Following https://www.python.org/dev/peps/pep-0440/#post-releases | https://www.python.org/dev/peps/pep-0440/#post-release-separators you can start with .post0 and further non-negative numbers.
Jason R. Coombs
@jaraco
Aug 15 2018 11:23
Fine with linking sources in changelog. I do that pretty religiously, although I typically prefer to link to the issue rather than the PR (if there are both) as usually someone will want to know why the change was made and only secondarily how.
I’m not a fan of post releases. They feel mostly unnecessary to me. If changes are sufficient to warrant a release, seems they’re sufficient to warrant a version bump.
Colin Dente
@colindente_twitter
Aug 15 2018 13:30
@ingoogni thanks for the suggestion. I'll take a look at MQTT
Sviatoslav Sydorenko
@webknjaz
Aug 15 2018 13:58
@jaraco I used that to add Python 3.7 platform trove classifier to metadata, for example. It's not really worth a bugfix-level/patch release, because it does not in fact add any value to code, but would fix the representation of the dist in the Warehouse.
By the way, we actively use alpha/dev releases in aio-libs for the purpose of testing pre-releases, which turned out to be very useful.
Ernesto Celis
@ecelis
Aug 15 2018 23:05
@jaraco Hello, I read the comments on the PR cherrypy/cherrypy/pull/1634 I'll take a look on these