0.12.3 release

[SylvainCorlay]

This issue is meant to track the progress towards 0.12.3

• merge / review "OHLC Selection" by @ibdafna Ohlc selections #990
• merge / review "avoid calling relayout too often" by @maartenbreddels performance: avoid calling relayout too often #993

[kaiayoung]

merge / review "Pie: Fix label display" by @martinRenou #1000

• This addresses a regression from 0.11.x -> 0.12.x

[martinRenou]

merge / review "Fix simple typo: resepect" -> respect #987 by @timgates42

merge / review "Fixing unwanted scrollbar when BQPlot figures are wrapped in a VBox" #941 by @ibdafna #990

[martinRenou]

Pie bug fix on the selection: #1008
MarketMap relayout debounce: #1017
Cleaning: #1014 and #1011
GridHeatMap selection fix: #1018
MarketMap font_style not applied: #1019

[martinRenou]

Review/merge #969

[jasongrout]

I just released 0.12.3, so perhaps what is left can be on 0.12.4? A check of the above PRs shows that these are left:

• Pie: Split draw function into sub-functions #1008
• MarketMap: Debounce relayout calls #1017
• Scatter: default_opacities -> opacities #1011

And this one is backwards-incompatible, so not a candidate for 0.12.x:

• Remove BaseModel #1014

Am I missing any more?

[martinRenou]

#1014 is backward-incompatible for the TypeScript package, so I guess it is safe to add it to 0.12.x

[martinRenou]

#1029 is also an important fix for when the plot is inside a Tab widget.
#1030 fixes some issues on the selection

[jasongrout]

#1014 is backward-incompatible for the TypeScript package, so I guess it is safe to add it to 0.12.x

If it is backwards-incompatible, then it is not safe to go in 0.12.x, right?

[martinRenou]

I mean the TypeScript package would need to go from 0.5.x to 0.6.0, but the Python package can stay in 0.12.x, don't you think? It is only backward-incompatible on the TypeScript package.

[jasongrout]

bqplot 0.12.3 depends on the js package ^0.5.3. So if you installed bqplot js package 0.6, it would not be compatible.

[martinRenou]

Well, we would need to bump the js package specification in the Python package to make it work. But the Python package would not be backward-incompatible from the user perspective.

[jasongrout]

(This is part of the reason why I advocate for the model_module_version and view_module_version to actually be the attribute spec version, not the actual js version. In this case, since the model attributes actually do not change, there is no reason for an upgrade in the js package to require a bump in the python package, other than the assumption that the attribute spec version is actually the js package version)

[jasongrout]

Suppose I have bqplot 0.12.3 installed, and I jupyter labextension install bqplot. If we bump the js package version, it won't work. If I upgrade to 0.12.4, it would work. Is that too confusing to users?

Have we had major upgrades in the js package before with only minor upgrades in the python package?

[martinRenou]

Suppose I have bqplot 0.12.3 installed, and I jupyter labextension install bqplot. If we bump the js package version, it won't work. If I upgrade to 0.12.4, it would work. Is that too confusing to users?

I agree it is confusing, I guess it is a very good argument against bumping the js package version without bumping the Python one.

Have we had major upgrades in the js package before with only minor upgrades in the python package?

I made a PR adding in the README the Python/TypeScript version mapping: https://github.com/bloomberg/bqplot/pull/1021/files and it looks like we did not do that since 0.10. The 0.9 version was a bit weird though:

| `back-end (Python)` | `front-end (JavaScript)` |
|---------------------|--------------------------|
| 0.9.1               | 0.3.0beta                |
| 0.9.0               | 0.2.3                    |

[martinRenou]

This is part of the reason why I advocate for the model_module_version and view_module_version to actually be the attribute spec version, not the actual js version

👍 👍 👍 👍 I totally agree with that

[jasongrout]

Yes, that is weird in 0.9.

[jasongrout]

👍 👍 👍 👍 I totally agree with that

The two points @SylvainCorlay always brings up are:

1. It is more confusing since there is yet another version number to keep track of. My response is usually "Yes, but it definitely is more powerful and clearly separates the concerns"
2. There is no easy mapping from widget data to js version needed to run, so for example our various html widgets that load js dynamically from unpkg/jsdelivr would have a harder time figuring out what to load. I've proposed having a registry mapping protocols to versions (perhaps as an npm package that could be dynamically loaded first).

[martinRenou]

I suppose this can be closed now