Ipykernel releases and branches

Open
#1,399 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
python
Domain
release

Research direction

Review the proposed branch sequence for main, 6.x, the anyio branch, and commit 7603443b, along with the release steps for 6.30.0 and 7.0.0. Confirm the required maintainer coordination and repository branch protections first; done means the branch layout and releases match the plan without disrupting existing pull requests or downstream version gating.

Written by the indexing model from the issue text.

Description

maintenance

(Reposted from Jupyter Zulip)

There are some plans for ipykernel releases and branch manipulations that I am sharing here for maximum exposure. All comments gratefully received.

The latest ipykernel release was 6.29.5 in July 2024. The current main branch has almost but not quite complete implementations of anyio (instead of tornado) and subshells (JEP91) and it was originally intended that these would be in a 7.0.0 release. However, there are concerns about the use of anyio going forward so I have instead backported subshells to the current 6.x branch so it can be released without anyio (issue #1387).

The release of ipykernel with subshells but not anyio could have been 6.30.0 or 7.0.0, but we have decided that 7.0.0 is more sensible. Subshells do not have to be used and the implementation is backward compatible in the sense that it passes all downstream tests in the ipykernel CI but now shell channel messages are handled in a separate thread and this could break downstream projects that are assuming otherwise, or that might now receive messages with different timings or in a different order. 7.0.0 will allow downstream projects to version gate on ipykernel<7 while they check and fix such issues.

We also think it wise to make a 6.30.0 release anyway based on the 6.x branch before subshells was added so that we can support the 6.x branch whilst projects are transferring to 7.

This needs some branch manipulation in the ipykernel repo:

  1. main renamed to anyio or some other name implying future or 8.x
  2. 6.x renamed to main
  3. 6.x before subshells were added (commit 7603443b) becomes the head of 6.x

I have sufficient permissions in the ipykernel repo to make these changes, but given the potential for messing things up I will only do in the presence of another maintainer; both Jason and Zach have previously said they might be available and are good choices being members of both the Jupyter Kernels Council and the EC.

Planned sequence of changes:

  1. Rename main to anyio, moving across all current PRs submitted against main
  2. Rename 6.x to main, set as default branch and update branch rules to protect against a push.
  3. Use commit 7603443b as the new head of 6.x
  4. Backport maintainance fixes from old main to new main and 6.x branches
  5. Release 6.30.0 from 6.x branch
  6. Release 7.0.0 from main branch
  7. Longer term discussion on the use of anyio vs tornado etc

I would like to start this soon, meaning weeks rather than months.

Dominant language
Python
Stars
734
Forks
411
Avg merge
1d 2h
Merged PRs (30d)
9

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ipython/ipykernel

All issues in ipython/ipykernel

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.