almet/dangerzone
1
0
Fork 0
mirror of https://github.com/freedomofpress/dangerzone.git synced 2025-04-28 18:02:38 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 11

Explain what happens when PySide6 gets updated

Browse source 
Explain what happens when we bump our `poetry.lock`, and a new
Pyside6 version. Also, have a step-by-step guide on how the maintainer
should create a new PySide6 RPM and update FPF's repo, so that
Dangerzone can be released.
This commit is contained in:
Alex Pyrgiotis 2024-01-30 11:55:12 +02:00
parent 46d5827772
commit 3e10fd1df4
No known key found for this signature in database
GPG key ID: B6C15EBA0357C9AA
2 changed files with 26 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

27
RELEASE.md
View file

@ -7,6 +7,8 @@ This section documents the release process. Unless you're a dangerzone developer
Before making a release, all of these should be complete:
- [ ] [Add new Linux platforms and remove obsolete ones](#add-new-platforms-and-remove-obsolete-ones)
- [ ] Bump the Python dependencies using `poetry lock`
- [ ] [Check for new PySide6 versions](#check-for-new-pyside6-versions)
- [ ] Update `version` in `pyproject.toml`
- [ ] Update `share/version.txt`
- [ ] Update the "Version" field in `install/linux/dangerzone.spec`
@ -48,6 +50,30 @@ In case of an EOL version:
* Consult the previous paragraph, but also `grep` your way around.
2. Add a notice in our `CHANGELOG.md` about the version removal.
## Check for new PySide6 versions
When a new PySide6 version has been released, we will get notified because the
nightly CI tests on `freedomofpres/python3-pyside6-rpm` will start failing.
Even if we miss these notifications, we will see failing builds in the
Dangerzone repo once we update our `poetry.lock` file. More specifically,
`./dev_scripts/env.py --distro fedora [...] build` will start failing, because
it won't be able to find a PySide6 RPM for the new version.
The Dangerzone maintainer should do the following:
1. Check the changelog for the new PySide6 version, and ensure it doesn't
introduce a breaking change.
2. Clone locally the https://github.com/freedomofpress/python3-pyside6-rpm repo.
3. Bump the PySide6 version and create a new PySide6 RPM for the supported
Fedora versions.
4. Copy it under the `dist/` directory of the Dangerzone repo.
5. Create an end-user build environment with `./dev_scripts/env.py --distro fedora [...] build`
6. Test that the Dangerzone UI works properly.
7. Ship the new PySide6 RPMs in our Fedora repo
(https://github.com/freedomofpress/yum-tools-prod)
8. Send a PR to the Dangerzone repo, with the new `poetry.lock` file.
## Large Document Testing
Parallel to the QA process, the release candidate should be put through the large document tests in a dedicated machine to run overnight.
@ -61,7 +87,6 @@ These tests will identify any regressions or progression in terms of document co
To ensure that new releases do not introduce regressions, and support existing
and newer platforms, we have to do the following:
- [ ] Bump the Python dependencies using `poetry lock`
- [ ] Make sure that the tip of the `main` branch passes the CI tests.
- [ ] Make sure that the Apple account has a valid application password and has
agreed to the latest Apple terms (see [macOS release](#macos-release)

2
dev_scripts/qa.py
View file

@ -16,8 +16,6 @@ CONTENT_QA = r"""## QA
To ensure that new releases do not introduce regressions, and support existing
and newer platforms, we have to do the following:
- [ ] In `.circleci/config.yml`, add new platforms and remove obsolete platforms
- [ ] Bump the Python dependencies using `poetry lock`
- [ ] Make sure that the tip of the `main` branch passes the CI tests.
- [ ] Make sure that the Apple account has a valid application password and has
agreed to the latest Apple terms (see [macOS release](#macos-release)