Updated outdated deployment steps #3266
Conversation
Signed-off-by: Christopher Petito <47751006+krissetto@users.noreply.github.com>
| * Make sure a release note for the changes included since the last published version is present in [docs/change-log.md](./docs/change-log.md); | ||
| * Go to the [`Release`](https://github.com/docker/docker-py/actions/workflows/release.yml) GitHub action page and click on `Run workflow`. Here: | ||
| * Insert the version number you want to give to the new package, **without** the `v.` prefix (eg. `7.1.0`). This version should correspond with the one written in [docs/change-log.md](./docs/change-log.md); | ||
| * Make sure `Dry run` is checked; |
There was a problem hiding this comment.
Not sure we need to document the dry-run option, or ossify it as part of the actual release process, as it's just a debugging/testing tool. At most, I'd explain what it does i.e. "If dry-run is checked, then the package is build but a release is not created/uploaded to pypi"
There was a problem hiding this comment.
my logic here was "better safe than sorry" (considering past events), but i'm ok with changing this :)
There was a problem hiding this comment.
It removes "if-branching" from the steps and can be followed as-is in a sense
There was a problem hiding this comment.
to clarify my point, I just mean that running a dry-run first is not a necessary step of the release process, so I don't think we should document it as such, since it might introduce confusion "do I have to do a dry run before releasing?". Instead we could just explain what it does (and if we want, mention something like "it's advisable to test the release pipeline before release by checking the "dry-run" option).
There was a problem hiding this comment.
Yeah I get your point. I agree that technically speaking a dry run is not necessary, but I'd argue it should be part of the "release process" so that people double check the version number, and only those in-the-know (or confident enough) should skip it at their discretion.
I'm saying this mostly because the result of the pipeline is yes a "draft release" on github, but at that point of the process the package has already been published to pypi and users might be downloading it before we realize and correct any potential issue.
No super hard feelings here, lets see if others have also differing opinions on this
There was a problem hiding this comment.
I don't disagree, I just think that including "dry-run" in that section removes clarity about what it actually does. The same can be achieved by separately explaining what "dry-run" does, and strongly advising it's use.
Updated CONTRIBUTING docs so the deployment steps reflect the current GitHub action based workflow