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.

Sign up for GitHub

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

Jump to bottom

[DISCUSS] Release strategy in relation to Kernel Provider #190

Closed
echarles opened this issue Mar 13, 2020 · 7 comments
Closed

[DISCUSS] Release strategy in relation to Kernel Provider #190

echarles opened this issue Mar 13, 2020 · 7 comments

Comments

@echarles
Copy link
Member

echarles commented Mar 13, 2020 •
edited
Loading

This is a place to summarise the discussion we had during the weekly meeting. We have gone through a few options. My understanding was a that the following got the most support from the participants. Here is my interpretations, please comment/amend:

  1. Further work in master in needed to have jupyterlab extension fully operational.
  2. Once jupyterlab extension operational, release master as 1.0.0 (stable) on top of which other extensions can be built (voila, ntreact...)
  3. Create a maintenance branch 1.x from the 1.0.0 release. That branch goal is to apply any needed fixes reported by the extensions builders. As it is not the goal to apply new feature on that branch, it is likely that master will diverge from branch 1.x.
  4. Any new feature will be applied on master branch. This includes the Kernel Provider Kernel providers #112. It sounds logical to merge as soon as possible the Kernel Providers in master after release 1.0.0.
  5. After release of 1.0.0, branch 1.x can create 1.x releases (1.1.0, 1.2.0...) with fixes. The features committed to master do not have to be back-ported to 1.x.
  6. After release of 1.0.0, master will result in a 2.0.0 release once ready with Kernel Provider.

@Zsailer @kevin-bates @vidartf
@echarles echarles mentioned this issue Mar 18, 2020
Closed
@echarles
Copy link
Member Author

@afshin

@echarles
Copy link
Member Author

@davidbrochart

@echarles
Copy link
Member Author

I have done more work those last days to get JupyterLab aligned with #180

https://dev.azure.com/jupyterlab/jupyterlab/_build/results?buildId=5634 shows green, except for the following steps:

@echarles
Copy link
Member Author

The proposed plan TBD during next weekly meeting:

@davidbrochart
Copy link
Contributor

This release strategy looks good to me. We also need to back-port every bug fix from the 1.x branch to master, that would avoid ending up in the situation we were in in jupyter_client.

@echarles
Copy link
Member Author

We also need to back-port every bug fix from the 1.x branch to master

+1

@echarles
Copy link
Member Author

Closing as jupyter/enhancement-proposals#45 has not been merged.

Zsailer added a commit to Zsailer/jupyter_server that referenced this issue Nov 18, 2022
@Zsailer
Adding Hubble metric collection (jupyter-server#190)
2824e06 
* add inital hubble port from @jialin-zhang4

* refactor hubble module

* add initial tests

* add one more test

* some more updates

* add client

* more refactoring

* don't validate cert in tests

* capture other events

* cleaner matcher

* Update data_studio_jupyter_extensions/configurables/hubble.py

* Update data_studio_jupyter_extensions/configurables/hubble.py

* Update data_studio_jupyter_extensions/configurables/hubble.py

Co-authored-by: Steve Silvester <ssilvester@apple.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@echarles @davidbrochart