search

jupyterlab / frontends-team-compass

A repository for team interaction, syncing, and handling meeting notes across the JupyterLab ecosystem.
https://jupyterlab-team-compass.readthedocs.io/en/latest/
BSD 3-Clause "New" or "Revised" License
57 stars 30 forks source link

(Lab council) Vote to revise the JupyterLab major version lifecycle #235

Closed JasonWeill closed 4 months ago

JasonWeill commented 5 months ago

name: "Revise the JupyterLab major version lifecycle" about: Revise JupyterLab's major version lifecycle to end maintenance one year after the next major version has its first generally available release

Discussed in https://github.com/jupyterlab/team-compass/issues/231

Proposal:

  1. Adopt a revision to the JupyterLab release cycle: a major version of JupyterLab will receive updates until one year after the following major version's first generally available release.
  2. To aid in the transition, JupyterLab 3 will continue to publish patch releases to address low-risk critical bug fixes for three months after its nominal end of maintenance date of May 15, 2024.

Low-risk critical bug fixes are defined as those that:

Per the Jupyter decision-making guide, "After the proposal is seconded by another member of the council, members have seven days to vote."

Votes

JasonWeill commented 5 months ago

@jupyterlab/jupyterlab-council Please vote above! Once someone has seconded this proposal, the team will have 7 days to vote.

andrii-i commented 5 months ago

Voted "yes" but we need to make sure to notify numerous impacted JupyterLab 3 users about the change.

Do we have anything planned for it? In my opinion we should use experience of Notebook 7 release and communication around it including warning via banner in UI and text in terminal for users of older versions.

JasonWeill commented 5 months ago

I have a draft blog post about it; if approved, we should publish it and mention it, ideally multiple times, on social media.

ivanov commented 5 months ago

I am not opposed to this change, but I would encourage reflection on whether JupyterLab should release major versions as frequently as it does, given the concern for a large chunk of users still on JupyterLab 3. For example, browsers release major version at an even faster clip, but their functionality, including 3rd party extensions typically continue to work without users being aware of what version they are on.

krassowski commented 5 months ago

There might be some backlash, which I infer from seeing comments by users testing 4.0.x seeing regressions, including critical regressions still not being addressed. 29 out of 49 issues describing regressions introduced in 4.0.0 remain open. I would like to acknowledge the regressions in the announcement, add a call for action, and promise to review PRs which address the regression as a priority.

Edit: I added my suggested wording on this to the draft announcement - please make it better:

The JupyterLab team recognises that, as in any software, a few regressions were introduced in JupyterLab 4.0 and a number of them remain to be addressed. At core, Project Jupyter is driven by volunteers, community contributions, and support from users (both individual and corporate), whom we ask for patience and assistance in resolving any regressions that may block the upgrade to the newer version. The JupyterLab maintainers are committing to review any pull requests submitted to address regressions as a priority over pull requests introducing new features.

The fix is approved by at least two JupyterLab maintainers

I don't think this is realistic, unless we can get more council members to review regularly (even 1 review each month would be great).

krassowski commented 5 months ago

Wording suggestion on the rules (I included yt in the draft announcement, but wanted to highlight here to), instead of:

be reasonably small/low complexity so their vetting and review doesn't require a massive work investment and has low potential to open doors for new vulnerabilities/bugs

could we say:

The fix includes tests, is reasonably small and low in complexity, and the author communicates actively with maintainers who review their work.

I don't think that any fix (for critical bug or not) should open doors for new vulnerabilities, so I don't think it needs to be there. I think that giving a concrete criterion (needs to have tests) is better than saying "should not open doors to new bugs" because this is hard to assess, especially for first time contributors.

JasonWeill commented 5 months ago

I revised the draft blog post's Google Doc to reflect @krassowski 's comments: https://docs.google.com/document/d/1jO-MksEAQwcGS_u0oXGCY9NNSfS6FeNA2h86nXxQAoM/edit

I left open the comment about two ship-its being required; I'm OK with only one approval, and I'm curious about what other council members think.

JasonWeill commented 4 months ago

@jupyterlab/jupyterlab-council A quick reminder to please vote if you haven't already! The typical vote duration is 7 days, so let's decide on Wednesday, February 7, anywhere on Earth.

JasonWeill commented 4 months ago

Of 22 council members, the results as of this morning are:

The quorum is met (68% participation, minimum 50%) and a majority of nonblank votes are "Yes". Per the decision-making guide, this vote passes.