New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix backwards compatibility for Running extension api in #6895 #7219
Comments
We haven't merged any 2.0 PRs into master, concentrating instead on 1.2 PRs. Another option is to branch off 1.x at this point, before #6895 in the tree, and consider master to be 2.0 alpha. Then we'll have three active branches: master (2.0 alpha), 1.x (1.2 alpha), and 1.1.x (currently at 1.1.3). If we want to backport to 1.1.4, we'd first merge to master, then backport to 1.x, then presumably backport that backport to 1.1.x. That would ensure that all the fixes that made it into 1.1.x actually made it into 1.x too. CC @blink1073 as well |
@Queuecumber - sorry I didn't see that #6895 was backwards incompatible with 1.x in the review. Would you like to make it backwards compatible (so that the constructor signature before #6895 works), or we can revert it for now and re-merge it for 2.0 in January? You mentioned elsewhere that you were wanting to use it, but I'm not sure if you need it before 2.0 (in January). |
Which constructor needs to be changed? I can take a look at it today |
Ok I see it was linked above |
@jasongrout let's discuss at the meeting tomorrow |
When I was experimenting, I thought that maybe the two existing running managers could be moved into the running extension for backwards compatibility, and then moved out again for 2.0 when we can have a breaking change. But before proceeding too far on this, we'll discuss this in our meeting tomorrow (you're welcome to join, by the way: https://github.com/jupyterlab/jupyterlab#weekly-dev-meeting) |
For now, we've branched off 1.x which does not include the PR in question, and master is now 2.0 alpha, which does include the PR. So that means the PR is now going into 2.0. @Queuecumber, if you need this in the 1.x series, someone will need to backport it to be backwards compatible. |
(2.0 is targeted for January 2020) |
I was going to use it for an extension but given my time constraints I think it can wait until next year |
Okay, let's close this issue then. Thanks again for taking that PR up and pushing it through. |
#6895 seems to have introduced a backwards compatible change: https://github.com/jupyterlab/jupyterlab/pull/6895/files/38efb83021c3a9734dd6bb59120502ada8bbb724#r325053066
It looks like we can revert and put that PR in 2.0, or we can figure out how to make it backwards compatible for 1.2.
The text was updated successfully, but these errors were encountered: