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

Backport PR #22442 on branch 6.x (PR: Update contributing, release and maintenance instructions for backporting) #22517

Merged
merged 1 commit into from
Sep 16, 2024
Merged

Backport PR #22442 on branch 6.x (PR: Update contributing, release and maintenance instructions for backporting) #22517

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 1 addition & 4 deletions Announcements.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -111,8 +111,7 @@ For a complete list of changes, please see our
[changelog](https://github.com/spyder-ide/spyder/blob/6.x/CHANGELOG.md)

Spyder 5.0 has been a huge success and we hope 6.0 will be as successful. For that we
fixed 123 bugs, merged 292 pull requests from about 22 authors and added more than
3098 commits between these two releases.
fixed 123 bugs and merged 292 pull requests from about 22 authors.

Don't forget to follow Spyder updates/news on the project's
[website](https://www.spyder-ide.org).
Expand Down Expand Up @@ -167,8 +166,6 @@ I'm pleased to announce the second beta of our next major version: Spyder **6.0*

We've been working on this version for more than one year now and it's working
relatively well. We encourage all people who like the bleeding edge to give it a try.
This release candidate version includes more than 74 commits over our latest release
candidate (6.0.0rc1).

Spyder 6.0 comes with the following interesting new features and fixes:

Expand Down
43 changes: 6 additions & 37 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -124,47 +124,18 @@ $ python runtests.py

## Spyder Branches

When you start to work on a new pull request (PR), you need to be sure that your work is done on top of the correct Spyder branch, and that you base your PR on Github against it.

To guide you, issues on Github are marked with a milestone that indicates the correct branch to use. If not, follow these guidelines:

* Use the `5.x` branch for bugfixes only (*e.g.* milestones `v5.0.1` or `v5.1.2`)
* Use `master` to introduce new features or break compatibility with previous Spyder versions (*e.g.* milestones `v6.0beta1` or `v6.0beta2`).

You should also submit bugfixes to `5.x` or `master` for errors that are only present in those respective branches.

To start working on a new PR, you need to execute these commands, filling in the branch names where appropriate:
To start working on a new pull request you need to execute these commands, filling in the branch name where appropriate:

```bash
$ git checkout <SPYDER-BASE-BRANCH>
$ git pull upstream <SPYDER-BASE-BRANCH>
$ git checkout master
$ git pull upstream master
$ git checkout -b <NAME-NEW-BRANCH>
```


### Changing the base branch

If you started your work in the wrong base branch, or want to backport it, you can change the base branch using `git rebase --onto`, like this:

```bash
$ git rebase --onto <NEW-BASE-BRANCH> <OLD-BASE-BRANCH> <YOUR-BRANCH>
```

For example, backporting `my_branch` from `master` to `5.x`:

```bash
$ git rebase --onto 5.x master my_branch
```


## Making contributions that depend on pull requests in spyder-kernels

Spyder and spyder-kernels are developed jointly because a lot of communication happens between them in order to run code written in the editor in the IPython console. The way the branches on their respective repos are linked appears in the table below:

| Spyder branch | Associated spyder-kernels branch |
| ------------------- | --------------------------------- |
| 5.x | 2.x |
| master (future 6.x) | master (future 3.x) |
Spyder and spyder-kernels are developed jointly because a lot of communication happens between them in order to run code written in the editor in the IPython console.

For this reason, a clone of spyder-kernels is placed in the `external-deps` subfolder of the Spyder repository. The instructions on this section will help you in case you need to make changes that touch both repositories at the same time.

Expand All @@ -176,7 +147,7 @@ echo 'source /path/to/git-subrepo/.rc' >> ~/.bashrc
source ~/.bashrc
```

As an example, let's assume that (i) your Github user name is `myuser`; (ii) you have two git repositories placed at `~/spyder` and `~/spyder-kernels` that link to `https://github.com/myuser/spyder` and `https://github.com/myuser/spyder-kernels` respectively; and (iii) you have two branches named `fix_in_spyder` and `fix_in_kernel` in each of these git repos respectively. If you want to open a joint PR in `spyder` and `spyder-kernels` that link these branches, here is how to do it:
As an example, let's assume that (i) your Github user name is `myuser`; (ii) you have two git clones placed at `~/spyder` and `~/spyder-kernels` that link to `https://github.com/myuser/spyder` and `https://github.com/myuser/spyder-kernels` respectively; and (iii) you have two branches named `fix_in_spyder` and `fix_in_kernel` in each of these git repos respectively. If you want to open a joint PR in `spyder` and `spyder-kernels` that link these branches, here is how to do it:

* Go to the `~/spyder` folder, checkout your `fix_in_spyder` branch and replace the spyder-kernels clone in the `external-deps` subfolder by a clone of your `fix_in_kernel` branch:

Expand Down Expand Up @@ -207,11 +178,9 @@ As an example, let's assume that (i) your Github user name is `myuser`; (ii) you
* When your `fix_in_kernel` PR is merged, you need to update Spyder's `fix_in_spyder` branch because the clone in Spyder's repo must point out again to the spyder-kernel's repo and not to your own clone. For that, please run:

```
$ git subrepo pull external-deps/spyder-kernels -r https://github.com/spyder-ide/spyder-kernels.git -b <branch> -u -f
$ git subrepo pull external-deps/spyder-kernels -r https://github.com/spyder-ide/spyder-kernels.git -b master -u -f
```

where `<branch>` needs to be `2.x` if your `fix_in_spyder` branch was done against Spyder's `5.x` branch; and `master`, if you did it against our `master` branch here.


## Making contributions that depend on pull requests in python-lsp-server or qtconsole

Expand Down
36 changes: 16 additions & 20 deletions MAINTENANCE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,38 +1,34 @@
These are some instructions meant for maintainers of this repo.

* To avoid pushing to our main repo by accident, please use `https` for your `usptream` remote. That should make git to ask for your credentials (at least in Unix systems).
* After merging a PR against the stable branch (e.g. `5.x`), you need to immediately merge it against `master` and push your changes to Github.
For that you need to perform the following steps in your local clone:

- git checkout 5.x
- git fetch upstream
- git merge upstream/5.x
- git checkout master
- git merge 5.x
- Commit with the following message:
* After merging a PR that needs to be included in stable branch (e.g. `6.x`), you need to call the `meeseeksdev` bot by adding a comment to the same PR with the followng syntax:

Merge from 5.x: PR #<pr-number>
`@meeseeksdev please backport to 6.x`

Fixes #<fixed-issue-number>
* If `meeseeksdev` fails to do the backport, you need to manually open a PR against the stable branch to do it with the following actions:

If the PR doesn't fix any issue, the second line is unnecessary.
- git push upstream master
- `git checkout 6.x`
- `git checkout -b backport-of-pr-<number>`
- `git cherry-pick <commit that was merged to master for that PR>`
- Solve conflicts

* To merge against `master` a PR that involved updating our spyder-kernels subrepo in the stable branch (e.g. `5.x`), you need to perform the following actions:
* If a PR that involved updating our spyder-kernels subrepo and needs to be included in the stable branch (e.g. `6.x`), you need to manually create a PR against it with the following actions:

- git checkout master
- git merge 5.x
- git reset -- external-deps/spyder-kernels
- git checkout -- external-deps/spyder-kernels
- git commit with the files left and the same message format as above.
- git subrepo pull external-deps/spyder-kernels
- `git checkout 6.x`
- `git checkout -b backport-of-pr-<number>`
- `git cherry-pick <commit that was merged to master>`
- `git reset -- external-deps/spyder-kernels`
- `git checkout -- external-deps/spyder-kernels`
- `git commit` with the files left
- `git subrepo pull external-deps/spyder-kernels`

* If a PR in spyder-kernels solves an issue in Spyder but was not part of a PR that updated its subrepo, you need to open one that does precisely that, i.e. update its subrepo, in order to fix that issue.

The same goes for the python-lsp-server and qtconsole subrepos.

* There's a bot that constantly monitors all issues in order to close duplicates or already solved issues and inform users what they can do about them (basically wait to be fixed or update).

The patterns detected by the bot and the messages shown to users can be configured in `.github/workflows/duplicates.yml` (only avaiable in our `master` branch because there's no need to have it in `5.x`).
The patterns detected by the bot and the messages shown to users can be configured in `.github/workflows/duplicates.yml` (only avaiable in our `master` branch because there's no need to have it in the stable one).

Please open a PR to add new messages or update previous ones, so other members of the team can decide if the messages are appropriate.
70 changes: 46 additions & 24 deletions RELEASE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,20 @@

To release a new version of Spyder you need to follow these steps:


## Create backport PR for new minor versions

Before releasing a new minor version (e.g. 6.1.0 after 6.0.x) that needs to include many changes only available in `master`, it's necessary to create a PR to backport those changes to the stable branch.

For that you need to run the following commands:

- `git checkout 6.x`
- `git checkout -b backport-for-minor-version`
- `git diff master 6.x > minor.patch`
- `patch -p1 -R < minor.patch`
- `git add .` and `git commit -m "Backport changes for X.X.X"`


## Update translation strings (at least one week before the release)

* Install [gettext-helpers](https://github.com/spyder-ide/gettext-helpers) from source.
Expand Down Expand Up @@ -32,6 +46,7 @@ To release a new version of Spyder you need to follow these steps:

https://github.com/spyder-ide/spyder/issues/14117


## Before starting the release

### Merge translations from Crowdin
Expand Down Expand Up @@ -73,15 +88,11 @@ To release a new version of Spyder you need to follow these steps:

* Don't forget to remove your local checkout of `translate/<branch-name>` because that's going to be outdated for next time.

* Update the `master` and `<branch-name>` branches as necessary. For example, if translations were done for the stable branch `6.x`, you could do the update with
* Update the `<branch-name>` branch as necessary. For example, if translations were done for the stable branch `6.x`, you could do the update with

git checkout 6.x
git fetch upstream
git merge upstream/6.x
git checkout master
git merge 6.x
Merge from 6.x: PR #xxxxx
git push upstream master

### Update core dependencies

Expand Down Expand Up @@ -130,7 +141,7 @@ To release a new version of Spyder you need to follow these steps:

### Check release candidate

* Update version in `__init__.py` (set release version, remove '.dev0', add 'rcX'), then
* Update version in `__init__.py` (set release version, remove 'dev0', add 'rcX'), then

git add .
git commit -m "Release X.X.XrcX [ci skip]"
Expand All @@ -146,26 +157,24 @@ To release a new version of Spyder you need to follow these steps:

* If one of the previous steps fail, merge a fix PR and start the process again with an incremented 'rcX' commit.

## To do the PyPI release and version tag

* Close the current milestone on Github
## Update Changelog and Announcements

* git pull or git fetch/merge the respective branch that will be released (e.g `6.x` - stable branch or `master` - alphas or betas of a new major version).
* Create a PR in master to update those files by following the steps below.

* For a new major release (e.g. version 6.0.0 after 5.5.6):
* For a new major release (e.g. 6.0.0):

- `git checkout -b 6.x`
- `git checkout master`
- Update version in `__init__.py` to reflect next major version as dev version (i.e `7.0.0.dev0`).
- `git add .` and `git commit -m "Bump version to 7.0"`
- `git checkout 6.x`
- In `CHANGELOG.md`, move entry for current version to the `Older versions` section and add one for the new version.
- `git add .` and `git commit -m "Add link to changelog of new major version"`
- In `.github/workflows/test-*.yml`, add `6.*` to the `branches` sections and remove the oldest branch from them (e.g. `4.*`).
- `git add .` and `git commit -m "CI: Update workflows to run in new stable branch [ci skip]"`

* Update `changelogs/Spyder-X.md` (`changelogs/Spyder-6.md` for Spyder 6 for example) with `loghub spyder-ide/spyder -m vX.X.X`
* For the first alpha of a new major version (e.g 7.0.0a1):

- When releasing the first alpha of a new major version (e.g. Spyder 7), you need to add a new file called `changelogs/Spyder-X+1.md` to the tree (`changelogs/Spyder-7.md` for Spyder 7 for example).
- After that, add `changelogs/Spyder-X+1.md` to `MANIFEST.in`, remove `changelogs/Spyder-X.md` from it and add that path to the `check-manifest/ignore` section of `setup.cfg`.
- Add a new file called `changelogs/Spyder-X+1.md` to the tree (e.g. `changelogs/Spyder-7.md`).
- Add `changelogs/Spyder-X+1.md` to `MANIFEST.in`, remove `changelogs/Spyder-X.md` from it and add that path to the `check-manifest/ignore` section of `setup.cfg`.

* Update `changelogs/Spyder-X.md` (`changelogs/Spyder-6.md` for Spyder 6 for example) with `loghub spyder-ide/spyder -m vX.X.X`

* Add sections for `New features`, `Important fixes` and `New API features` in `changelogs/Spyder-X.md`. For this take a look at closed issues and PRs for the current milestone.

Expand All @@ -175,9 +184,26 @@ To release a new version of Spyder you need to follow these steps:

* `git add .` and `git commit -m "Update Announcements"`

* Once merged, backport the PR that contains these changes to the stable branch (e.g. `6.x`)


## To do the PyPI release and version tag

* 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 or `master` - alphas/betas/rcs of a new minor/major version).

* For a new major release (e.g. version 6.0.0 after 5.5.6):

- `git checkout -b 6.x`
- `git checkout master`
- Update version in `__init__.py` to reflect next minor version as dev version (i.e `6.1.0a1.dev0`).
- `git add .` and `git commit -m "Bump version to new minor version"`
- `git checkout 6.x`

* `git clean -xfdi` and select option `1`

* Update version in `__init__.py` (set release version, remove 'dev0')
* Update version in `__init__.py` (Remove '{a/b/rc}X' and 'dev0' for stable versions; or remove 'dev0' for pre-releases)

* `git add .` and `git commit -m "Release X.X.X"`

Expand All @@ -203,16 +229,12 @@ To release a new version of Spyder you need to follow these steps:

* `git tag -a vX.X.X -m "Release X.X.X"`

* Update version in `__init__.py` (add 'dev0' and increment minor)
* Update version in `__init__.py` (add 'a1', 'dev0' and increment patch version for stable versions; or increment alpha/beta/rc version for pre-releases)

* `git add .` and `git 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 with

git checkout master
git merge 6.x
git commit -m "Release X.X.X [ci skip]"
git push upstream master
git push upstream 6.x
git push upstream --tags

Expand Down