Skip to content
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

Closed
jasongrout opened this issue Sep 17, 2019 · 10 comments
Closed

Fix backwards compatibility for Running extension api in #6895 #7219

jasongrout opened this issue Sep 17, 2019 · 10 comments
Labels
status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Milestone

Comments

@jasongrout
Copy link
Contributor

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

@jasongrout jasongrout added this to the 1.2 milestone Sep 17, 2019
@jasongrout
Copy link
Contributor Author

jasongrout commented Sep 17, 2019

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

@jasongrout
Copy link
Contributor Author

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

@Queuecumber
Copy link
Contributor

Which constructor needs to be changed? I can take a look at it today

@Queuecumber
Copy link
Contributor

Ok I see it was linked above

@blink1073
Copy link
Member

@jasongrout let's discuss at the meeting tomorrow

@jasongrout
Copy link
Contributor Author

Which constructor needs to be changed? I can take a look at it today

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)

@jasongrout
Copy link
Contributor Author

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.

@jasongrout
Copy link
Contributor Author

(2.0 is targeted for January 2020)

@Queuecumber
Copy link
Contributor

I was going to use it for an extension but given my time constraints I think it can wait until next year

@jasongrout
Copy link
Contributor Author

Okay, let's close this issue then. Thanks again for taking that PR up and pushing it through.

@jasongrout jasongrout modified the milestones: 1.2, Reference Sep 19, 2019
@lock lock bot added the status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. label Oct 19, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 19, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Projects
None yet
Development

No branches or pull requests

3 participants