Dev instructions for new releases #467
Conversation
|
I added a checklist that people can copy/paste into issues to manage this process! |
choldgraf
force-pushed
the
release_instructions
branch
from
9220b73 to
225476c
Compare
There was a problem hiding this comment.
Fantastic @choldgraf @yuvipanda!
A few minor edits. This is great.
CONTRIBUTING.md
Outdated
| ## Releasing a new version of the helm chart | ||
|
|
||
| The following steps can be followed to release a new version of the Helm Chart. | ||
| This should happen approximately once every 5-7 weeks. |
There was a problem hiding this comment.
Presently, we expect a release approximately every 5-7 weeks.
CONTRIBUTING.md
Outdated
| - [ ] Make a CHANGELOG | ||
| - [ ] Generate and add the list of contributors | ||
| - [ ] Build and push a new Docker image to DockerHub | ||
| - [ ] Commit version bump in `Chartyaml` and `Values.yaml` |
| - [ ] Create and push a new tag for this release | ||
| - [ ] Create and publish a new GitHub release | ||
| - [ ] Write / publish a blog post based largely off of the CHANGELOG | ||
| - [ ] Set ReadTheDocs to begin using `latest` by default |
There was a problem hiding this comment.
Is there a reason for this?
There was a problem hiding this comment.
Ah nevermind. I see why a few lines down.
There was a problem hiding this comment.
think we could get away with just having docs that point to the last version a bit longer, then updating straight from last-version to new-version instead of going through latest?
There was a problem hiding this comment.
I'm inclined to just leave enough time before release (i.e. RC) to have the docs ready at the same point as the release of the charts. If the docs are radically off, then there should be a dot release perhaps. I'll defer to you and @yuvipanda but it would be great to release all at once as any minor docs changes will be available in latest anyway.
There was a problem hiding this comment.
Yeah, I think we can do this once enough of our docs get stable enough, but I think for now, we should keep this unfortunately. For example, we run into problems with GKE version needing to be bumped quite often still, so if we don't switch to latest users won't be able to even complete a setup
CONTRIBUTING.md
Outdated
| * [JupyterHub](https://github.com/jupyterhub/jupyterhub) | ||
| * [OAuthenticator](https://github.com/jupyterhub/oauthenticator)) | ||
|
|
||
| edit `contributors.py` to have the appropriate dates |
|
ok, latest push addresses comments + tries to clarify a bit how the documentation should be handled with new releases. LMKWYT! |
There was a problem hiding this comment.
Overall, a nice improvement. @choldgraf, a few things that I would like to get stated explicitly with the primary being that we go into a release with stable docs, tests and code.
I'm fine with latest existing for 2-4 weeks of the 5-7 week release cycle. I want to be very careful that we do not send a message that we can slack off on docs prior to a release.
| chart, {{release-name}}. Instructions for creating the release can be found in | ||
| [CONTRIBUTING.md](https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/master/CONTRIBUTING.md#releasing-a-new-version-of-the-helm-chart). | ||
| Below is the checklist for this release. | ||
|
|
There was a problem hiding this comment.
I would like to an explicit step 0: Code, tests, and documentation to support a release are stable.
There was a problem hiding this comment.
I'm firm on wanting this explicitly stated. This should be the goal even if it takes a release or two to get there.
There was a problem hiding this comment.
Definitely agree w/ you on this point 👍 my question only pertained to the other comment
CONTRIBUTING.md
Outdated
| - [ ] Generate and add the list of contributors | ||
| - [ ] Build and push a new Docker image to DockerHub | ||
| - [ ] Commit version bump in `Chart.yaml` and `Values.yaml` | ||
| - [ ] Update references in documentation to the new version |
There was a problem hiding this comment.
Update references in documentation to the new version (note: documentation should be stable and there should be no anticipated major changes to content).
|
|
||
| ### Extra step - release a documentation release | ||
|
|
||
| It is common that documentation changes are made shortly after a new release. |
There was a problem hiding this comment.
I'm inclined to say let's just do this as part of the release process (making the time window: 2 weeks or when the next release docs begin to be written).
Otherwise, we are generating more work for us and more confusion for the end user (a large portion will looks for the current version docs).
There was a problem hiding this comment.
IIRC the reasoning was that there are still a lot of large-ish changes to the docs happening, so it'd be best if the docs always show the latest updates until there's something written that doesn't apply to the currently-released helm chart.
What if we kept this behavior for one or two release cycles, and then once the docs stabilize we can start to just jump straight from last-version to next-version?
cc @yuvipanda in case you've got thoughts as well
There was a problem hiding this comment.
As long as the comment (Code, tests, and documentation to support a release are stable.) goes in as the first checklist step, I'm fine doing this as you propose for a couple of releases.
choldgraf
force-pushed
the
release_instructions
branch
from
8d2cc3d to
13b9509
Compare
|
@willingc what do you think about the latest push? I added a note at the end suggesting that this was temporary behavior, and added a first step of "stable code / docs / etc" to the checklist |
There was a problem hiding this comment.
Thanks @choldgraf. Looks fantastic. Love the note. Feel free to merge.
|
@yuvipanda wanna push the green button on this if you're 👍 on the language? |
|
Thanks for making this happen, @choldgraf! |
This adds more fleshed out instructions for cutting a new release, and was inspired by the most recent (v0.6) release of JupyterHub's helm chart. Somebody other than @choldgraf should test this out the next time we need to make a release!