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 Compatibility Check for Prereleases #7723

Merged
merged 5 commits into from Jan 7, 2020

Conversation

blink1073
Copy link
Member

@blink1073 blink1073 commented Jan 2, 2020

References

Fixes #7241

The previous behavior is as follows:

  • ^1.x is seen overlapping with ~2.0.0-x.y because 2.0.0-x.y is less than 2.0.0 in our logic
  • ^1.x is not seen as overlapping with ~2.0.0 (verified locally)

This changes the logic to always strip our prelease info when doing the version compatibility check.

With these changes, the latest @jupyter-widgets/jupyterlab-manager cannot be installed into the alpha release:

Conflicting Dependencies:
JupyterLab                        Extension              Package
>=2.0.0-alpha.0 <2.1.0            >=1.2.0 <2.0.0         @jupyterlab/application
>=4.0.0-alpha.0 <4.1.0            >=3.2.0 <4.0.0         @jupyterlab/coreutils
>=2.0.0-alpha.0 <2.1.0            >=1.2.0 <2.0.0         @jupyterlab/notebook
>=2.0.0-alpha.0 <2.1.0            >=1.2.0 <2.0.0         @jupyterlab/rendermime
>=2.0.0-alpha.0 <2.1.0            >=1.5.0 <2.0.0         @jupyterlab/rendermime-interfaces
>=5.0.0-alpha.0 <5.1.0            >=4.2.0 <5.0.0         @jupyterlab/services

However, an extension that declares a dependency on any prerelease version or final version of JupyterLab can be installed (tested with a local extension depending on "@jupyterlab/application": "^2.0.0-rc.0" and "@jupyterlab/application": "^2.0.0").

Code changes

Compare against final releases in the version compatibility check.

User-facing changes

Users can no longer install incompatible extensions during the prerelease cycle.

Backwards-incompatible changes

Incompatible extensions can no longer be installed.

@blink1073 blink1073 added this to the 2.0 milestone Jan 2, 2020
@jupyterlab-dev-mode
Copy link

@jupyterlab-dev-mode jupyterlab-dev-mode bot commented Jan 2, 2020

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link: Binder

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Jan 2, 2020

With these changes, the latest @jupyter-widgets/jupyterlab-manager cannot be installed into the alpha release:

That's too bad. So this comment isn't true anymore?

https://github.com/jupyterlab/jupyterlab/pull/7723/files#diff-f889c27ebc01f0305bbef39cfd65085bR1985-R1987

@blink1073
Copy link
Member Author

@blink1073 blink1073 commented Jan 2, 2020

The comment is still true. The extension author can just specify the new final version or any prerelease version and it will work.

# to not have to update their versions for each
# Jupyterlab prerelease version.
if x1.prerelease:
x1 = x1.inc('patch')
Copy link
Contributor

@jasongrout jasongrout Jan 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make this behavior an option in the function? As a standalone function, it's surprising that it ignores the prerelease option on just one end of one of the ranges. Would we get the same end result if we had an "increment prerelease" flag as an argument, and then just did this logic on both ends of both ranges?

Copy link
Member Author

@blink1073 blink1073 Jan 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, we can make this behavior optional in the standalone function. It only has an effect on the lower end of the range, since ~2.0.0-b1 gets interpreted originally as 2.0.0-b1 <= x < 2.1.0 and converted to 2.0.0 <= x < 2.1.0. By doing it on the lower end of the first argument, we are saying that we don't do compatibility checks within our own prerelease cycle only.

@jasongrout jasongrout merged commit 3c2f3cb into jupyterlab:master Jan 7, 2020
10 checks passed
@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Jan 7, 2020

Thanks!

@lock lock bot added the status:resolved-locked label Feb 6, 2020
@lock lock bot locked as resolved and limited conversation to collaborators Feb 6, 2020
@blink1073 blink1073 deleted the extension-compat branch Mar 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status:resolved-locked tag:Build System
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants