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

Bump controls version to 1.2.0 #2017

Merged
merged 8 commits into from Mar 29, 2018

Conversation

@jasongrout
Copy link
Member

commented Mar 23, 2018

We do this now so we can test the backwards compatibility before the release.

@jasongrout jasongrout added this to the 7.2 milestone Mar 23, 2018

@jasongrout

This comment has been minimized.

Copy link
Member Author

commented Mar 23, 2018

I just changed the logic of the JupyterLab manager in efea844 - if a specific module version is requested (not a semver range), then it defaults to the ^ semver range to get a compatible module.

This would fix the problem we see in #2006, for example. If someone wants to insist on a specific version, they should use the range specifier =1.2.3.

@SylvainCorlay - thoughts? This does change the behavior for plain versions, but I think it makes the behavior more intuitive and better addresses the various places we need version numbers. I think it also probably makes sense to make the same change in the html manager?

@jasongrout jasongrout referenced this pull request Mar 23, 2018
5 of 5 tasks complete
@jasongrout

This comment has been minimized.

Copy link
Member Author

commented Mar 27, 2018

@vidartf

This comment has been minimized.

Copy link
Member

commented Mar 28, 2018

For future reference it would be nice if this had some tests outlining basic expected behavior. A side effect of this is that it is impossible for packages to lock one version to another (or that would require a one-element range).

@jasongrout

This comment has been minimized.

Copy link
Member Author

commented Mar 28, 2018

A side effect of this is that it is impossible for packages to lock one version to another (or that would require a one-element range).

Yes, it would require a semver range =1.2.3

@jasongrout

This comment has been minimized.

Copy link
Member Author

commented Mar 28, 2018

(If this is too big of a change for a minor release, we can probably hold off on something like this until 8.0)

jasongrout added some commits Mar 28, 2018

Special-case the new semver range logic to the Jupyter widgets base/c…
…ontrols packages.

This resolves the backwards-incompatibility issues for other libraries with applying this logic to all modules, but still fixes #2006.

@jasongrout jasongrout force-pushed the jasongrout:version12 branch from ed31a84 to 8f56f66 Mar 28, 2018

@jasongrout

This comment has been minimized.

Copy link
Member Author

commented Mar 28, 2018

(If this is too big of a change for a minor release, we can probably hold off on something like this until 8.0)

Since this is technically a backwards-incompatible change in general, I special-cased the changes to just the Jupyter-widgets/[base,controls] packages. We can take up the issue of making the more general change for 8.0 later.

@jasongrout

This comment has been minimized.

Copy link
Member Author

commented Mar 28, 2018

For future reference it would be nice if this had some tests outlining basic expected behavior. A side effect of this is that it is impossible for packages to lock one version to another (or that would require a one-element range).

The last commits roll back the behavior for general packages.

@jasongrout jasongrout merged commit 375832c into jupyter-widgets:master Mar 29, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@jasongrout jasongrout referenced this pull request Mar 30, 2018
9 of 10 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.