Remove minor version number from kernel name (currently e.g. "julia-1.1")

[NHDaly]

After the Julia 1.0 release, minor version changes are supposed to be non-breaking, but before this commit, upgrading julia would break your notebooks (in CI) since the kernel can't be found. ~This commit changes IJulia to only use the major version number in the kernel name so that tests will succeed b/w minor julia releases.~

EDIT: This PR adds options to set the specversion and specdebugdesc so that upgrading Julia version won't break automated CI tests for existing jupyter notebooks that expect a given kernel name.

---

Fixes #852

[stevengj]

Minor versions are backwards compatible but they can still add new features. That is, code that works in Julia 1.0 should work in 1.2, but not necessarily vice versa.

When you run a notebook, if it can't find the "Julia 1.x" kernel, it still gives you the option to choose the kernel (so that you can select "Julia 1.y"), so the notebooks aren't really broken.

[stevengj]

I see the point about automated tests in #852, however.

[stevengj]

Arguably this should be fixed in Jupyter itself — if it can't find the Foo x.y kernel, shouldn't it automatically use Foo x.z for z > y?

[NHDaly]

Arguably this should be fixed in Jupyter itself — if it can't find the Foo x.y kernel, shouldn't it automatically use Foo x.z for z > y?

I think it currently does do this, but for different language_info.versions, not for the kernel name.

That is, if you have a kernel named julia-1, with kernel version 1.2.3, it will try to find that exact version number when it opens, and if it can't it will print a warning and fall back to an available version, following something like the rule you just outlined. Which i think is pretty good behavior for us as well?

EDIT: I meant language_info.version in the kernel_info_reply, not kernelspec.version

[NHDaly]

I think it currently does do this, but for different language_info.versions, not for the kernel name.

Hmm, so after some further exploration, I believe that no, Jupyter doesn't implement any kind of behavior as precise as what we'd like. As far as I can tell, Jupyter's behavior is to just "open the kernel with the exact same name, and then, update the listed version from the response we get from the kernel_info_reply." :( which is disappointing. I was hoping it would at least print a message saying "HEY we can't find a kernel with the expected version; falling back to an older version". But it did not. Instead, it happily just opened the older version without any information about it happening.

So maybe this isn't actually a good approach.

Arguably this should be fixed in Jupyter itself — if it can't find the Foo x.y kernel, shouldn't it automatically use Foo x.z for z > y?

Unfortunately, as far as I can tell, we are the only language kernel I know of that puts a major and minor version number in our kernel name. I don't think that using the kernel name for versioning is a common convention at all. I do agree, though, that it's pretty weird that there isn't version info in the kernel.json files so that it could implement precisely the fall-back/fall-forward behavior we expected above. They definitely should do that. 😞

[NHDaly]

I see the point about automated tests in #852, however.

Hmm, so since this approach isn't a good one (per your points about minor releases being forward compatible but not backwards compatible [or the other way around?]), may I propose an alternative?

In our case, we are actually using a custom-named jupyter kernel. The reason we are encountering this issue is that our custom-named kernel has the julia version number appended to it always and automatically.

Could we instead simply expose a switch that allows the user to control that versioning somehow? Either by allowing the user to specify a custom version number (which I like best, since it gives maximal control), or providing a boolean flag that allows the user to toggle between including the minor version number or not?

What do you think about that? I'll make that change now and push it up so we can see what the proposal might look like. Thanks for your careful thoughts on this @stevengj! :)

[NHDaly]

After the latest commit i've just pushed, we can now create a kernel that will accept changes to the minor version:

IJulia.installkernel("julia-ci", specversion="$(VERSION.major)")

or that will accept any version of julia:

IJulia.installkernel("julia-ci", specversion="")

[NHDaly]

Okay! PTAL :) I think that the solution presented in this PR is much cleaner now: simply allow users to also customize the specversion and specdebugdesc so that that they can control the entire name of the kernel.

This will allow users who need to run automated CI for jupyter notebooks to use a custom kernel name that will be resilient against minor julia version upgrades and/or debug builds of julia.

Please let me know if this PR looks okay! Thanks again for your help so far, @stevengj

[twavv]

Minor versions are backwards compatible but they can still add new features. That is, code that works in Julia 1.0 should work in 1.2, but not necessarily vice versa.

FWIW, Python is simply versioned as "Python 2" or "Python 3" and it doesn't seem to be a big issue in practice (how many Julians are really waiting to upgrade to the latest most greatest most multithreading-capable version???).