141 lines
4.8 KiB
ReStructuredText
141 lines
4.8 KiB
ReStructuredText
Notes for maintainers.
|
|
|
|
Pre-release test plan
|
|
---------------------
|
|
|
|
0. If no release branch exists, fork the version numbers in the release branch
|
|
(vX.Y-branch) and the main branch. See "Cutting a release branch", below,
|
|
for details.
|
|
|
|
The rest of these steps should be done in the release branch::
|
|
|
|
git checkout vX.Y-branch
|
|
|
|
1. Make tox happy on the following first-party platforms:
|
|
|
|
- Windows 10
|
|
- the latest macOS
|
|
- the latest Ubuntu LTS
|
|
|
|
2. Make tox happy on other popular Linux distributions as resources allow.
|
|
Doing this in a container is fine.
|
|
|
|
- Arch
|
|
- the latest Ubuntu release (if different than the latest LTS)
|
|
- Debian stable (if its Python 3 is still supported)
|
|
- Debian testing
|
|
- Fedora
|
|
|
|
3. Build alpha N (N=1 to start, then N=2 if you need more commits, etc.) and
|
|
upload to pypi. See "Building and uploading the release wheels" below for
|
|
a procedure.
|
|
|
|
4. Install the alpha on test platforms. ::
|
|
|
|
pip3 install west==X.YaN
|
|
|
|
5. Create and update a default (Zephyr) workspace on all of the platforms from
|
|
1., using the installed alpha::
|
|
|
|
west init zephyrproject
|
|
cd zephyrproject
|
|
west update
|
|
|
|
Make sure zephyrproject/zephyr has a branch checked out that matches the
|
|
default branch used by zephyr itself.
|
|
|
|
6. Do the following Zephyr specific testing in the Zephyr workspace on all of
|
|
the platforms from 1. Skip QEMU tests on non-Linux platforms, and make sure
|
|
ZEPHYR_BASE is unset in the calling environment. ::
|
|
|
|
west build -b qemu_x86 -s zephyr/samples/hello_world -d build-qemu-x86
|
|
west build -d build-qemu-x86 -t run
|
|
|
|
west build -b qemu_cortex_m3 -s zephyr/samples/hello_world -d build-qemu-m3
|
|
west build -d build-qemu-m3 -t run
|
|
|
|
# This example uses a Nordic board. Do this for as many boards
|
|
# as you have access to / volunteers for.
|
|
west build -b nrf52dk_nrf52832 -s zephyr/samples/hello_world -d build-nrf52
|
|
west flash -d build-nrf52
|
|
west debug -d build-nrf52
|
|
west debugserver -d build-nrf52
|
|
west attach -d build-nrf52
|
|
|
|
(It's still a pass if ``west build`` requires ``--pristine``.)
|
|
|
|
7. Assuming that all went well (if it didn't, go fix it and repeat), update
|
|
__version__ to 'X.Y.Z' (i.e. drop the 'aN' suffix that denotes alpha N), tag
|
|
the release (see "Tagging the release" for a procedure) and upload to PyPI
|
|
(see "Building and uploading the release wheels" for a procedure).
|
|
|
|
8. Send email to the Zephyr lists, announce@ and users@, notifying them of the
|
|
new release. Include 'git shortlog' data of the new commits since the last
|
|
release to give credit to all contributors.
|
|
|
|
Building and uploading the release wheels
|
|
-----------------------------------------
|
|
|
|
You need the zephyr-project PyPI credentials for the 'twine upload' command. ::
|
|
|
|
git clean -ffdx
|
|
python3 setup.py sdist bdist_wheel
|
|
twine upload -u zephyr-project dist/*
|
|
|
|
The 'git clean' step is important. We've anecdotally observed broken wheels
|
|
being generated from dirty repositories.
|
|
|
|
Tagging the release
|
|
-------------------
|
|
|
|
Create and push a GPG signed tag. ::
|
|
|
|
git tag -a -s vX.Y.Z -m 'West vX.Y.Z
|
|
|
|
Signed-off-by: Your Name <your.name@example.com>'
|
|
|
|
git push origin vX.Y.Z
|
|
|
|
Cutting a release branch
|
|
------------------------
|
|
|
|
To cut a new release branch, just get confirmation from the other
|
|
maintainers that it's time and push it manually to GitHub.
|
|
|
|
The release branch for minor version vX.Y.0 should be named "vX.Y-branch".
|
|
|
|
Subsequent fixes for patch versions vX.Y.Z should go to vX.Y-branch after
|
|
being backported from main (or the other way around in case of an urgent
|
|
hotfix).
|
|
|
|
In vX.Y-branch, in src/west/version.py, set __version__ to X.Y.0a1.
|
|
Don't include this commit in the main branch.
|
|
|
|
Summary of the outcome:
|
|
|
|
- precondition: vX.Y-branch does not exist, main is at version X.(Y-1).99
|
|
- postcondition: v.X.Y-branch exists and is at version vX.Y.0a1, main is at
|
|
version vX.Y.99
|
|
|
|
Check if west.manifest.SCHEMA_VERSION also needs an update. The rule is that
|
|
SCHEMA_VERSION should be updated to X.Y if this release is introducing
|
|
manifest schema changes that earlier versions of west cannot parse.
|
|
|
|
Don't change SCHEMA_VERSION from its current value if the manifest syntax is
|
|
fully compatible with what west X.(Y-1) can handle.
|
|
|
|
Don't introduce incompatible manifest changes in patch versions. That violates
|
|
semantic versioning. If v0.7.3 can parse it, v0.7.2 should be able to parse it,
|
|
too.
|
|
|
|
Send this as a pull request to the newly created release branch. (This
|
|
requires a PR and review because getting the release number wrong would
|
|
upload potentially buggy software to anyone who runs 'pip install west'.)
|
|
|
|
In main (but not the release branch), set __version__ to X.Y.99. Send this
|
|
commit as a PR to main. Make sure any SCHEMA_VERSION updates are reflected in
|
|
main too.
|
|
|
|
From this point forward, the main branch is moving independently from the
|
|
release branch.
|