JupyterLab Desktop uses tbump to bump JupyterLab and the application versions. You can install using:
pip install tbump
JupyterLab Desktop needs to be versioned with the same major, minor and patch versions as the JupyterLab it bundles. For example, if JupyterLab Desktop is based on JupyterLab 3.1.12, a valid JupyterLab Desktop version is 3.1.12-1 to 3.1.12-n. Last number after -
is used as the build number
. This version matching is enforced before JupyterLab Desktop installer binaries are published.
JupyterLab version, that JupyterLab Desktop bundles, is determined by @jupyterlab/metapackage
dependency version in the yarn.lock.
If the JupyterLab version is not changing with the new JupyterLab Desktop release then only increment the build number after -
(for example 3.1.12-2
to 3.1.12-3
). However, if JupyterLab version is changing with the new JupyterLab Desktop release then reset the build number after -
to 1 (for example 3.1.12-3
to 3.1.13-1
).
In order to change the JupyterLab version bundled with the application:
-
Update all
@jupyterlab
package dependencies in package.json usingyarn set_jupyterlab_version <new-jlab-version>
<new-jlab-version>
must match a released JupyterLab version such as3.1.13
. This command will update dependencies with@jupyterlab
scope. -
Bump the application version using
tbump
tonew-jlab-version-1
tbump --only-patch <new-jlab-version>-1
-
Update
@jupyter-widgets/jupyterlab-manager
version in package.json for ipywidgets if a compatible newer version is available. -
Update
ipywidgets
python package version inenv_installer/construct.yaml
if there is a compatible newer version available.
Note that after updating the bundled JupyterLab version, it is necessary to bump JupyterLab Desktop version using tbump
as described in the section below. Run check_version_match
script before committing the changes to ensure version integrity.
yarn check_version_match
-
Create a new release on GitHub as
pre-release
. Set the releasetag
to the value of target application version and prefix it withv
(for examplev3.1.12-1
for JupyterLab Desktop version3.1.12-1
). Enter release title and release notes. Release needs to stay aspre-release
for GitHub Actions to be able to attach installers to the release. -
Bump application version using
tbump
. If same JupyterLab version is being bundled then only increment the build number after-
. If JupyterLab version is incremented then reset the build number to 1.Example: same JupyterLab version (
3.1.12
), bump from3.1.12-2
to3.1.12-3
tbump --only-patch 3.1.12-3
Example: changing JupyterLab version (to
3.1.13
), bump from3.1.12-3
to3.1.13-1
tbump --only-patch 3.1.13-1
tbump will list changes to be applied, confirm the changes to proceed with apply.
-
Make sure that application is building, installing and running properly by following the distribution build instructions locally
-
Create a branch preferably with the name
release-v<new-version>
. Add a commit with the version changes and create a PR. The PR must be created from main repo and not from a fork. This is necessary for GitHub Actions to be able to attach installers to the release. -
GitHub Actions will automatically create installers for each platform (Linux, macOS, Windows) and upload them as release assets. Assets will be uploaded only if a release of type
pre-release
with tag matching the JupyterLab Desktop's version with av
prefix is found. For example, if the JupyterLab Desktop version in the PR is3.1.12-2
, the installers will be uploaded to a release that is flagged aspre-release
and has a tagv3.1.12-2
. New commits to PR will overwrite the installer assets of the release. -
Once all the changes are complete, and installers are uploaded to the release then publish the release.