To release a new version of Spyder you need to follow these steps:
Before releasing new minor or major versions, it's necessary to:
-
Rename the current stable branch (the commands below considers that
6.1.0is going to be released after6.0.x):git checkout 6.xgit branch -m 6.0.xgit push upstream 6.0.xgit push upstream --delete 6.x
-
Create a new stable branch:
git checkout mastergit checkout -b 6.xgit checkout master- Update version in
__init__.pyto reflect next minor version as dev version (i.e6.2.0a1.dev0when being close to release6.1.0, or7.1.0a1.dev0for7.0.0). git add .andgit commit -m "Bump version to new minor version"git push upstream 6.xgit push upstream master
-
Checkout stable branch
git checkout 6.x
-
Install gettext-helpers from source.
-
Create a new PR to update our
*.potand*.pofiles by runningspyder-gettext scan spyder -
Check that no warnings are emitted by that command. If they are, then you need to
- Open a new PR against
masterto fix them. - Backport that PR to the stable branch.
- Rebase the PR's branch created in the previous step on top of those changes.
- Open a new PR against
-
Merge that PR.
-
Close the current translation PR, i.e. the one with the title
New Crowdin updates. -
Delete the
translate/<branch-name>branch associated to that PR. -
Go to the integrations page on Crowdin:
-
Press
Sync nowthere to open a new translation PR. -
Send a message to translators on Crowdin to update their translations:
An example of that message can be found in
-
Checkout the translations branch with
git checkout translate/<branch-name> -
Squash all commits in that branch to leave only one with the command
git rebase --interactive HEAD~Nwhere N is the number of commits on it.
-
Change the commit message with
git commit --amendto be
Update and compile translations [ci skip] -
Generate the
mofiles by runningspyder-gettext compile spyder -
Remove
mofiles that are still not part of version control. -
Add those files to the previous commit with
git add . git commit --amend --no-edit -
Push your changes to the translation PR with
git push -f upstream translate/<branch-name> -
Rename the PR title to be
PR: Update translations from Crowdin. -
Merge the PR.
-
Don't forget to remove your local checkout of
translate/<branch-name>because that's going to be outdated for next time. -
Update the
<branch-name>branch as necessary. For example, if translations were done for the stable branch6.x, you could do the update withgit checkout 6.x git fetch upstream git merge upstream/6.x
-
Release a new version of
spyder-kernels, if required. -
Release a new version of
python-lsp-server, if required. -
Release a new version of
qtconsole, if required. -
Merge PRs on Conda-forge that update the
spyder-kernels,python-lsp-serverandqtconsolefeedstocks (usually an automatic PR will appear that can be either merged as it is or be used as boilerplate):-
spyder-kernels: https://github.com/conda-forge/spyder-kernels-feedstock -
python-lsp-server: https://github.com/conda-forge/python-lsp-server-feedstock -
qtconsole: https://github.com/conda-forge/qtconsole-feedstock
Notes:
- Review carefully the release notes of those packages to see if it's necessary to add new dependencies or update the constraints on the current ones (e.g.
jedi >=0.17.2).
-
-
For spyder-kernels:
-
Switch to the stable branch
git checkout 6.x -
Create a new branch in your fork with the name
update-spyder-kernels -
Update version in
-
setup.py -
spyder/dependencies.py -
requirements/{main,windows,macos,linux}.yml -
binder/environment.yml -
spyder/plugins/ipythonconsole/__init__.py(look up for the constantsSPYDER_KERNELS_MIN_VERSIONandSPYDER_KERNELS_MAX_VERSION)Note: Usually, the version of
spyder-kernelsfor validation in the IPython Console only needs to be updated for minor or major releases of that package or when doing alphas for Spyder. For bugfix releases the value should remain the same to not hassle users using custom interpreters into updatingspyder-kernelsin their environments. However, this depends on the type of bugs resolved and if it's worthy to reinforce the need of an update even for those versions.
-
-
Commit with
git add . git commit -m "Update spyder-kernels" -
Update our subrepo with the following command, but only if a new version is available!
git subrepo pull external-deps/spyder-kernels -
Merge this PR to the stable branch.
-
-
For other dependencies
-
Create a new branch in your fork with the name
update-core-deps -
Update the version of any packages required before the release in the following files:
setup.py(look up for theinstall_requiresvariable and also for theLoosen constraints to ensure dev versions still workpatch)spyder/dependencies.pyrequirements/{main,windows,macos,linux}.ymlbinder/environment.yml
-
Commit with
git add . git commit -m "Update core dependencies" -
Update our subrepos with the following commands, but only if new versions are available!
git subrepo pull external-deps/python-lsp-server git subrepo pull external-deps/qtconsole -
Merge this PR following the procedure mentioned on
MAINTENANCE.md
-
-
For pre-releases of a new bug fix version
-
Switch to the stable branch
git checkout 6.x -
Update version in
__init__.py(set release version, remove 'dev0', add 'rcX'), thengit add . git commit -m "Release X.X.XrcX" -
Follow the instructions in the To do the PyPI release and version tag section, from the
git clean -xfdione onwards. -
Publish the release to Conda-forge by doing a PR against the
rcbranch of the spyder-feedstock repo.-
Create branch for the update
git checkout rc git fetch upstream git merge upstream/rc git checkout -b update_X.X.XrcX -
Update
rcbranch in the Spyder feedstock with the latest changes in themainone:-
Create patches between the branches and apply them
git checkout main git fetch upstream git merge upstream/main git diff main rc recipe/ ":(exclude)recipe/conda_build_config.yaml" > recipe.patch git diff main rc conda-forge.yml > conda-forge.patch git checkout update_X.X.XrcX patch -p1 -R < recipe.patch patch -p1 -R < conda-forge.patch -
Fix conflicts, if any, and add new files.
-
Commit with
Update rc channel.
-
-
Update the Spyder version to the rc one just released and reset build number to
0. -
Create PR with the title
Update to X.X.XrcX -
Re-render the feedstock.
-
-
Publish the release in our Github Releases page to check the installers are built as expected.
-
Download and test the installation of the resulting installers.
-
-
For pre-releases of a new minor or major version:
-
Switch to master
git checkout master -
Update version in
__init__.py(set release version, remove 'dev0', add 'rcX'), thengit add . git commit -m "Release X.X.XrcX [ci skip]" -
Push changes to master
git push upstream master -
Manually activate the following workflows (see Running a workflow) via the
Run workflowbutton: -
Download and test the installation of the resulting artifacts.
-
-
If one of the previous steps fails, merge a fix PR and start the process again with an incremented 'rcX' commit.
-
Create a PR in master to update those files by following the steps below.
-
For a new major release (e.g. 6.0.0):
- In
CHANGELOG.md, move entry for current version to theOlder versionssection and add one for the new version. git add .andgit commit -m "Add link to changelog of new major version"- In
.github/workflows/test-*.yml, add6.*to thebranchessections and remove the oldest branch from them (e.g.4.*). git add .andgit commit -m "CI: Update workflows to run in new stable branch [ci skip]"
- In
-
For the first alpha of a new major version (e.g 7.0.0a1):
- Add a new file called
changelogs/Spyder-X+1.mdto the tree (e.g.changelogs/Spyder-7.md). - Add
changelogs/Spyder-X+1.mdtoMANIFEST.in, removechangelogs/Spyder-X.mdfrom it and add that path to thecheck-manifest/ignoresection ofsetup.cfg.
- Add a new file called
-
Update
changelogs/Spyder-X.md(changelogs/Spyder-6.mdfor Spyder 6 for example) withloghub spyder-ide/spyder -m vX.X.X -
Add sections for
New features,Important fixesandNew API featuresinchangelogs/Spyder-X.md. For this take a look at closed issues and PRs for the current milestone. -
Add changelog for new version to
spyder/plugins/application/widgets/appeal_page/changelog.md(onlyNew featuresandImportant fixes). -
Update
CHANGELOG_URLinspyder/plugins/application/widgets/status.pyto point to the changelog for the new version. -
git add .andgit commit -m "Update Changelog [ci skip]" -
Update Announcements.md (this goes to our Google group) removing the outdated announcement of the same kind (major, minor, or beta/release candidate)
-
git add .andgit commit -m "Update Announcements" -
Update org.spyder_ide.spyder.appdata.xml adding the version to be released over the
<releases>tag -
git add .andgit commit -m "Update metadata files" -
Once merged, backport the PR that contains these changes to the stable branch (e.g.
6.x)
-
Close the current milestone on Github
-
git pull or git fetch/merge the respective branch that will be released (e.g
6.x- stable branch ormaster- alphas/betas/rcs of a new minor/major version). -
Checkout stable branch:
git checkout 6.x
-
Update version in
__init__.py(Remove '{a/b/rc}X' and 'dev0' for stable versions; or remove 'dev0' for pre-releases) -
git add .andgit commit -m "Release X.X.X" -
git clean -xfdiand select option1 -
python setup.py sdistNote: This needs to be done on a Linux machine to prevent getting permission errors on executable files (see #21892 and #14494).
-
Activate environment with pip packages only
-
pip install -U pip setuptools twine wheel -
python setup.py bdist_wheelNote: This needs to be done on a Linux machine to prevent getting permission errors in executable files (see #21892 and #14494).
-
Install generated wheel locally and check for errors
-
twine check --strict dist/* -
twine upload dist/* -
Check in PyPI that the new release was published correctly
-
git tag -a vX.X.X -m "Release X.X.X" -
Update version in
__init__.py:- Add 'a1', 'dev0' and increment patch version for final version releases
- Add 'dev0' and increment alpha/beta/rc version for pre-releases
-
git add .andgit commit -m "Back to work [ci skip]" -
Push changes and new tag to the corresponding branches. When doing a stable release from
6.x, for example, you could push changes withgit push upstream 6.x git push upstream --tags
-
Merge PR on Conda-forge for Spyder. For that you can go to the spyder-feedstock repo and merge the corresponding PR for the new release (usually an automatic PR will appear that can be either merged as it is or be use as boilerplate).
Notes:
- Don't forget to add new dependencies and update constraints on the rest of them. For that, you need to compare line by line the contents of the
recipe/meta.yamlfile in the feedstock with setup.py
- Don't forget to add new dependencies and update constraints on the rest of them. For that, you need to compare line by line the contents of the
-
Update Binder related elements when the new Spyder version is available in Conda-forge:
- Update the Spyder version on the environment file (
binder/environment.yml) of the (spyder-stablebranch) in thebinder-environmentsrepo. - Update
environment.ymlfiles of themasterbranch ofbinder-environmentswith the contents of thebinder/environment.ymlfile present on this repo. - Update
environment.ymlfiles of the6.xbranches ofbinder-environmentswith the contents of thebinder/environment.ymlfile present on this repo.
- Update the Spyder version on the environment file (
-
Publish release in our Github Releases page:
- Copy the contents of the previous release description (updating the relevant information and links to point to the new Spyder version and changelog entry).
- Edit the previous release description to only have the changelog line.
-
Publish release announcement to our list (following Announcements.md) after the installers have been built.