Do 0.10.0 release (final release for Jlab 1.x) and then upgrade to Jlab 2.0

[telamonian]

Jupyterlab 2.0 marches towards release. The api is now (theoretically) locked down, so I think that the time is right to think about upgrading jupyterlab-git to be Jupyterlab 2.0 compatible.

I think we should cut a final Jupyterlab 1.x compatible release (which will be v0.10.0) of jupyterlab-git. Following that, we should then upgrade the master branch to be compatible with Jlab 2.0.

I've volunteered to help out with the Jlab 2.0 migration guide for extension devs. I'd like to do the 2.0 upgrades myself, and use my experiences as content for the guide. I'm also willing to handle the release, but if any of the other active maintainers (cough @fcollonval cough @kgryte) want to volunteer to do the release, I'd be happy to help get you the needed permissions on pypi and npmjs.

Does that sound like a reasonable plan to you guys?

[jaipreet-s]

This extension is integrated in various Cloud providers (GCP, GitLab, AWS) so it’s safe to assume we would want to keep 1.x support for backwards compatibility, at least for the foreseeable future. Having a “final” release for JL1.0 won’t leave room for back porting any bugs, fixes, or features.

One option, off the top of my head, is that the next release for jupyterlab-git to be 1.0, and all further 1.x versions track releases compatible with JupyterLab 1.x APIs, and then releases 2.x conform to the JL2.0 API. Master can track 2.x. One downside here is that ties jupyterlab-git's sementic versioning scheme to JupyterLab, but it does leave room for backporting bugs or fixes.

Also tagging @blink1073 for any ideas and recommendations

[telamonian]

Having a “final” release for JL1.0 won’t leave room for back porting any bugs, fixes, or features.

Backports are good. I'd argue that, for now, critical bugfixes can be backported to 0.10.x patch versions, and that there should be no expectation of feature backports. If someone does submit a PR with a feature backport, that can also be a 0.10.x release*.

In Jupyterlab core, we use the Meeseeksdev bot to manage backports. We can set this up for this repo as well.

One thing to note is that we will only be able to automate certain backports. Essentially, how easy it is to backport a given change will depend on how much that change overlaps with the changes needed to support Jupyterlab 2.0.

One option, off the top of my head, is that the next release for jupyterlab-git to be 1.0

I'd argue very strongly against us "graduating" to 1.0. We're on the right track, but jupyterlab-git still has a ways to go before it's up to snuff (w.r.t. the ecosystem of git gui tools). From a development point of view, I think we'd greatly benefit from at least a couple more versions in which things are free to change.

[*] For major version 0 there's no expectation of a frozen public API. I'd also argue that we don't really have a "public API", at least not in the sense that there are other packages which depend on it.

[kgryte]

I agree with @telamonian on the release, migration, and backport plan.

[kgryte]

My only further thought is that it would be good to figure out what needs to be in that final JLab 1.x compatible release. There are a few outstanding bugs and features which should likely be resolved before we focus exclusively on JLab 2.0.

[fcollonval]

I agree with @telamonian and @kgryte

Regarding what should be included in 0.10.0, I would say that the most important one seems: #493 and #509. They correct the history panel and the rest API (return valid json to avoid user reporting "error JSON decode...").

And the nice to have would be #505, #515, #518 & #519.

The main questions is what time could we spend for review (I definitely can review #518 by next Monday).

@telamonian If you grant me accept, I can carry out the release to share that burden.

[blink1073]

@fcollonval, I sent you invites for pypi and npm. Please let me know when you accept npm so I can give you access to this particular package.

[blink1073]

As far as versioning goes, we could make a 0.20 release that targets JupyterLab 2.0, which leaves room to have 0.11-0.19 releases targeting JupyterLab 1.0. We are going to do something similar for packages in JupyterLab core starting after 2.0, to leave room for minor releases between major releases of the top level package without needing to keep versions in sync between branches.

[jaipreet-s]

In Jupyterlab core, we use the Meeseeksdev bot to manage backports. We can set this up for this repo as well.

Yea, I’d follow JLab’s infrastructure for automated back porting as well . I’m in agreement about back porting in general and that master should track JLab2.0

As far as versioning goes, we could make a 0.20 release that targets JupyterLab 2.0, which leaves room to have 0.11-0.19 releases targeting JupyterLab 1.0.

This addressed my concerns about not leaving room for backports/fixes and other good stuff and not having a "final" release for JLab 1.x

I'd argue very strongly against us "graduating" to 1.0. We're on the right track, but jupyterlab-git still has a ways to go before it's up to snuff (w.r.t. the ecosystem of git gui tools).

@telamonian : I'm surprised to hear this since there has been consensus previously on releasing 1.0 but we didn't pull the plug as it gives us leeway in making backwards incompatible change. Regardless, this is not the right issue for this discussion but we should formulate crisp plan of tasks needed to get to 1.0. For now, 0.1x.y for tracking JL1.z works.

[fcollonval]

Thanks @blink1073 I accepted the npm invitation.