Release v2.0.0

[consideRatio]

The repo now contains breaking changes so the next release will be v2.0.0.

I think before release we should at least get the following open PRs to land:

• 84

• Either #86 or #85

• 81

• 90

I think also if we can't drive development of tests now, it won't get done - and specifically now before a release is when we would want to see tests go green as well. Due to that, I'd like to see us not settle for the above, but push to resolve:

• 68

[yuvipanda]

fwiw, I think #68 is going to be pretty fairly involved, and I don't think my near future schedule has time for that. I'm happy to provide code review if someone else wants to do that.

I also don't think #81 should block the release.

[yuvipanda]

My personal perspective is that we should really have very low barriers to release, as that helps get the software out to more people's hands - and that's the primary thing that potentially brings in new contributors, which is the lifeblood of keeping a project going and unburntout. Release early and release very often.

[consideRatio]

Release early and often is something I want too, and I find tests make it easier to do so. Contributing to a project would smoother for PR authors and maintainers if one can see tests go green.

We have not had any test for TurboVNC, and then things has broken. When things break after a release we probably get project involvement in a way, but it also require maintainers to react.

I'd like to contribute the "add test" maintenance up-front to reduce the risk of needing to do work reactively later.

This project isn't new, so I'm pushy for us to get a basic test for TurboVNC at this point as we say its supported. That would make me feel more comfortable contributing to this project in reviews etc, lowering the barrier to merge etc.

---

@yuvipanda what do you think about #88? I'm highly motivated to resolve #68, and that can be easily by doing #88 which I think is quite easy as well - but its something that merits up-front agreement I think.

[yuvipanda]

Yeah totally agree re: green tests making it easier to contribute. Happy to do code reviews!

If #88 is enough for you to consider #68 resolved I'm very happy for the approach described in #88 to go forward.

[consideRatio]

Excellent okay!

Yeah I formulated #68 as a starting point of ensuring we can start it successfully. I figure with such base environments in place, we can more easily run tests manually and then possibly also automate a few.

[yuvipanda]

@consideRatio you're right that having tests makes it easier to release.

I opened https://github.com/jupyterhub/jupyter-remote-desktop-proxy/pull/93 with an integration test that tests everything except novnc. It needs debugging for why it is failing in github actions, but works great on my (much faster) local machine. I hope that helps.

[yuvipanda]

@consideRatio with #94 merged (thank you), do you think this is ready for a release or needs #93? I'm not sure when I'll have time next to push on that, as it does work locally so this is github actions debugging at this point.

[consideRatio]

I'd like to see this major release ship with the breaking change of #91 as well, but with regards to testing I'm OK with the current state having a basic tiger + turbo test now.

Reamining:

• Fix (one liner) of #69
• Merge of (requring >=4.1.1 not yet released) #91

[yuvipanda]

Any other blockers to making a release?

[consideRatio]

I really wanted to have basic tests for turbovnc land before rather than after - with #101 I'm happy to go for a release!

[consideRatio]

• Blocked again by #106