jupyterlab

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

For major and minor versions, we are going through a full cycle of alpha, beta and release candidate versions. You can find more information about the release process at https://github.com/jupyterlab/jupyterlab/blob/main/RELEASE.md.

Repository on GitHub, which uses git. git is distributed.

We version the application with the semantic versioning pattern. That identifier matches the version available through git tag (with a prefix v), Python package manager (pip and conda) and the GitHub releases page (https://github.com/jupyterlab/jupyterlab/releases).

Each version is tagged as v<version_identifier>. This can be seen in the GitHub releases page: https://github.com/jupyterlab/jupyterlab/releases

Non-trivial release notes file in repository: https://github.com/jupyterlab/jupyterlab/blob/main/CHANGELOG.md.

We are also using the GitHub releases page: https://github.com/jupyterlab/jupyterlab/releases And the changelog is also accessible in the documentation website: https://jupyterlab.readthedocs.io/en/latest/getting_started/changelog.html

Release notes with an outline of enhancements, bug fixes, among others, including any publicly known vulnerabilities fixed are listed in the Security Fixes section of the appropriate release in the Github releases page, https://github.com/jupyterlab/jupyterlab/releases. One example of this is the JupyterLab 4.0.11 release https://github.com/jupyterlab/jupyterlab/releases/tag/v4.0.11

Bug reports must be carried out through GitHub: https://github.com/jupyterlab/jupyterlab/issues/new/choose

We use the GitHub issues tracker: https://github.com/jupyterlab/jupyterlab/issues

There is a weekly triage meeting organized by the dev community: https://github.com/jupyterlab/frontends-team-compass/issues/228

There is a weekly triage meeting organized by the dev community: https://github.com/jupyterlab/frontends-team-compass/issues/228

All issues are archived within GitHub. They can be searched for from the page: https://github.com/jupyterlab/jupyterlab/issues?q=is%3Aissue

The reporting vulnerability process is documented in https://github.com/jupyterlab/jupyterlab?tab=security-ov-file#readme

We only support private vulnerability reports as documented in https://github.com/jupyterlab/jupyterlab?tab=security-ov-file#readme

There are instructions, https://jupyterlab.readthedocs.io/en/latest/developer/contributing.html#installing-node-js-and-jlpm for setting up a local development environment for contributing to JupyterLab or other cases where one might make changes to the source code. With a few packages installed and running a few commands outlined in the documentation, JupyterLab can be built from source.

Two of the major frontend technologies used are Webpack, and Yarn. The tools used on the Python side include: build and hatch. Of these tools, Hatch is a relatively newer tool that over time is increasingly being used within the Python community.

The build system is based on JavaScript and Python building tools. For JavaScript, the tools are: Typescript compiler, yarn package manager and webpack bundler. For Python, the tools are: build, hatch and an custom-made builder hatch-jupyter-builder (licensed under BSD-3-Clause) (https://github.com/jupyterlab/hatch-jupyter-builder).

There are automated test suites that run tests for integration, documentation, visual regressions and unit testing. The test primarily use Playwright, Galata, Jest, and Pytest all of which are open source.

All code branches are including their own test suite and for each branch we do our best to add automated test for the functionalities.

We are running our test suite using GitHub actions on all protected branches and pull requests.

See https://github.com/jupyterlab/jupyterlab/actions

When new functionality is added, if tests are not already included in the pull requests, as a comment or part of the review process, the author of the pull request is usually asked to include those tests.

We are using pre-commit to execute multiple linters covering the Python and JavaScript code: https://github.com/jupyterlab/jupyterlab/blob/main/.pre-commit-config.yaml

We also have an internal integrity-validator tool (part of the core code).

We are releasing packages for Python on PyPI using the trusted publisher mechanism and JavaScript packages are digitally signed for publication on https://www.npmjs.com/.

Credentials are only needed for publishing new releases. Those are handled through CI secrets infrastructure or trusted publisher mechanism.

Among the static code analysis tools used are Ruff, and MyPy on the Python side and ESLint, and Prettier on the JavaScript side.

CodeQL analysis workflows are run on this repository.

The developer documentation outlining languages, tools and processes can be found in https://jupyterlab.readthedocs.io/en/stable/developer/contributing.html#languages-tools-and-processes. Checks in place assure that modified files are automatically formatted with the help of pre-commit.

All source code is written in TypeScript and Python, https://jupyterlab.readthedocs.io/en/stable/developer/contributing.html#languages-tools-and-processes

We don't use dynamic analysis tool (as of May 1st, 2024). But we do have some configuration on the server side to allow greater access to the application within the browser for integration tests: - expose_app_in_browser (available at runtime too): https://github.com/jupyterlab/jupyterlab/blob/9b757222dc775a22eb823282e266187071d61bee/jupyterlab/labapp.py#L581