Release v2.0.0 about jupyter-remote-desktop-proxy HOT 11 CLOSED

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

I opened #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.

from jupyter-remote-desktop-proxy.

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

from jupyter-remote-desktop-proxy.

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.

from jupyter-remote-desktop-proxy.

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.

from jupyter-remote-desktop-proxy.

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.

from jupyter-remote-desktop-proxy.

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.

from jupyter-remote-desktop-proxy.

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.

from jupyter-remote-desktop-proxy.

@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.

from jupyter-remote-desktop-proxy.

Any other blockers to making a release?

from jupyter-remote-desktop-proxy.

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

from jupyter-remote-desktop-proxy.

• Blocked again by #106

from jupyter-remote-desktop-proxy.