Design z2jh upgrade process

[yuvipanda]

We deploy a few z2jh instances, and I want us to have a clear cadence for upgrading them in sync with z2jh releases.

What I'd like is:

1. z2jh releases every 6 weeks
2. We upgrade a week after release

(1) takes time and effort right now, primarily to support @consideRatio - assuming he wants this to happen too. Once we have that, we can do this manually by calendar entries or automatically.

We could also designate some hubs to have a more cutting edge version, but we can deal with that later.

What do you think, @consideRatio & @GeorgianaElena?

[consideRatio]

@yuvipanda I'd be happy to work towards the ambition of having a 6 week release schedule in z2jh, and I think it would be very valuable to have regular adoption of releases to ensure there is feedback for iterations on fixes etc.

[yuvipanda]

@consideRatio yay! What do you think are the missing pieces towards such a release cadence?

[consideRatio]

Hmmmmmm we have technical instructions and procedure in RELEASE.md. It may benefit from some clarifications or changes to the procedure but it is quite updated technically.

Perhaps a schedule and allocation of responsibility? I love the thought of asking if someone would be willing to be responsible for cutting the release and then be available to help rather than do it myself in order to help onboard more people to this process.

Here may be relevant inspiration:

• https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md
• https://github.com/kubernetes/sig-release/blob/master/release-engineering/release-notes.md

[GeorgianaElena]

I'd be happy to learn about the release process of z2jh ❤️

Also, how do you feel about having a bot that we can use to remind us that we need to cut a new release?
I found this one: https://github.com/probot/reminders.

[consideRatio]

@GeorgianaElena wieeee! 🎉 ❤️!!

I also like the idea of having automation assistance to remind us to get things done!

[consideRatio]

2i2c upgrade process -> z2jh release process -> jupyterhub/kubespawner/chp/oauthenticator release process

All these repo's are now in relatively good shape to start cutting releases more frequently thankfully. I wonder if rather than thinking that z2jh should have a release cadence, that perhaps a set of JupyterHub projects should have a release cadence so help distributions like tljh and z2jh be updated with minimized delays following releases of dependency projects.

[yuvipanda]

I was thinking we could separate these out, since you'll often end up with something like 'this fix for jupyterhub must be in before we want a 1.4'.

I was thinking of following whatever pip does. Quoting,

The pip project has a release cadence of releasing whatever is on master every 3 months. This gives users a predictable pattern for when releases are going to happen and prevents locking up improvements for fixes for long periods of time, while still preventing massively fracturing the user base with version numbers.

This could lead to components (jupyterhub, etc) syncing with this, but not necessarily. Makes the release process much simpler! And since it will be frequent enough, missing a feature in a release isn't as big a deal.

[yuvipanda]

Maybe ping @pradyun to ask about his experience with the pip release cadence?

[consideRatio]

Thanks for thinking about this @yuvipanda!

I'm open to that, perhaps starting with regular releases would give other projects a rythm they can opt to align with? I would like to have a mental strategy for more than just z2jh.

I wonder if we could perhaps opt for a bit slower rythm than 6 weeks though, even though it would sound sensible for 2i2c to upgrade in that pace it feels a bit too intense to cut releases for a distribution. I think every two months would make it practically more easy as well, just thinking: "oh its an even month, so by the end we should push for releases, starting with dependency projects and finishing with the distributions like z2jh!"

[yuvipanda]

Yeah, totally! 6 weeks was just a suggestion. Here's pip's policy:

Our release months are January, April, July, October. The release date within that month will be up to the release manager for that release. If there are no changes, then that release month is skipped and the next release will be 3 months later.

We could do something similar. We could do 2 or 3 months as well.

[consideRatio]

I opened jupyterhub/team-compass#384, perhaps a topic for the next jh team meeting? (I added an agenda item!)

[consideRatio]

We have passed Z2JH 1.0 and I feel a lot more comfortable with quick releases at this point. The releases as happening quicker than every 6th week if there is something to release I'd say.

I suggest an action point for this would be to automate PR creations for when new Z2JH releases are out. Technically, to do that, I suggest we have a cron job running nightly that checks like this for the latest version.

helm show chart --repo https://jupyterhub.github.io/helm-chart/ jupyterhub | yq e '.version' -

Then, the script automatically modifies the Chart.yaml dependencies in basehub to reference that latest version and run a PR creating GitHub action that only creates/updates a PR if there was an actual change.