Difference between revisions of "Developers/Release process"
Jump to navigation
Jump to search
Uwe Hermann (talk | contribs) m |
m (Python3 versions) |
||
| (9 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
This is a list of steps we perform when creating a new | This is a list of steps we perform when creating a new release: | ||
* | *{{checkbox|unchecked}} Check if all relevant PRs are merged. | ||
* | *{{checkbox|unchecked}} Check the mailing list for relevant patches. | ||
* Check if the manpages are up-to-date. | *{{checkbox|unchecked}} Check if the manpages are up-to-date. | ||
* Test that '''make distcheck''' works without errors and creates a '''.tar.gz''' file. Unpack that file somewhere. | *{{checkbox|unchecked}} Check if "SR_PKG_CHECK([python3]...)" in configure.ac has all current versions included in the check. | ||
** Test that no files are missing, and no extra/unneeded files are in there (non-public header files, *.o files, and that kind of stuff). | *{{checkbox|unchecked}} Test that '''make distcheck''' works without errors and creates a '''.tar.gz''' file. Unpack that file somewhere. | ||
** Test that building | **{{checkbox|unchecked}} Test that no files are missing, and no extra/unneeded files are in there (non-public header files, *.o files, and that kind of stuff). | ||
** Test that installing | **{{checkbox|unchecked}} Test that building from that unpacked directory works without errors. | ||
** Test that running the newly installed | **{{checkbox|unchecked}} Test that installing from there works. | ||
** Test at least the demo driver, one hardware LA, one non-default input- and output driver, and one protocol decoder. The more tests the better, of course. | **{{checkbox|unchecked}} Test that running/using the newly installed library/program works fine. | ||
* Do all of the above tests on all supported platforms if possible, e.g. Linux, Windows, Mac OS X, FreeBSD. | **{{checkbox|unchecked}} Test at least the demo driver, one hardware LA, one non-default input- and output driver, and one protocol decoder. The more tests the better, of course. | ||
* Write release notes (containing user-visible, important changes) in the | *{{checkbox|unchecked}} Do all of the above tests on all supported platforms if possible, e.g. Linux, Windows, Mac OS X, FreeBSD. | ||
* If everything works OK, tag the new release in git via: '''git tag -a | *{{checkbox|unchecked}} Write release notes (containing user-visible, important changes) in the respective NEWS file(s). | ||
** Verify that the tag is placed correctly via '''git tag''' or '''gitk'''. | *{{checkbox|unchecked}} Increase the respective package version number. | ||
** Then, push it via '''git push --tags'''. | **{{checkbox|unchecked}} If there were any backwards-incompatible changes in libsigrok and/or libsigrokdecode, increase the respective lib version numbers too. | ||
* Now create the final tarball via '''make distcheck''' as described above, and upload it | **{{checkbox|unchecked}} Then, push your current status, including the version number change commit via '''git push'''. | ||
* Announce the new release in | *{{checkbox|unchecked}} If everything works OK, tag the new release in git via (for example): '''git tag -a "libsigrok-0.1.0" -m "libsigrok 0.1.0 release" <hash>'''. Replace '''<hash>''' with the commit hash that should be tagged. | ||
**{{checkbox|unchecked}} Verify that the tag is placed correctly via '''git tag''' or '''gitk'''. | |||
**{{checkbox|unchecked}} Then, push it via '''git push --tags'''. | |||
*{{checkbox|unchecked}} Now create the final tarball via '''make distcheck''' as described above, and upload it. | |||
*{{checkbox|unchecked}} In case of a client program (sigrok-cli / PV), create all pre-built binaries, upload them and make them available on the wiki for future reference. | |||
*{{checkbox|unchecked}} Announce the new release in the blog and on the mailing list. | |||
Latest revision as of 13:08, 29 September 2024
This is a list of steps we perform when creating a new release:
Check if all relevant PRs are merged.- Check the mailing list for relevant patches.
- Check if the manpages are up-to-date.
- Check if "SR_PKG_CHECK([python3]...)" in configure.ac has all current versions included in the check.
- Test that make distcheck works without errors and creates a .tar.gz file. Unpack that file somewhere.
- Test that no files are missing, and no extra/unneeded files are in there (non-public header files, *.o files, and that kind of stuff).
- Test that building from that unpacked directory works without errors.
- Test that installing from there works.
- Test that running/using the newly installed library/program works fine.
- Test at least the demo driver, one hardware LA, one non-default input- and output driver, and one protocol decoder. The more tests the better, of course.
- Do all of the above tests on all supported platforms if possible, e.g. Linux, Windows, Mac OS X, FreeBSD.
- Write release notes (containing user-visible, important changes) in the respective NEWS file(s).
- Increase the respective package version number.
- If there were any backwards-incompatible changes in libsigrok and/or libsigrokdecode, increase the respective lib version numbers too.
- Then, push your current status, including the version number change commit via git push.
- If everything works OK, tag the new release in git via (for example): git tag -a "libsigrok-0.1.0" -m "libsigrok 0.1.0 release" <hash>. Replace <hash> with the commit hash that should be tagged.
- Verify that the tag is placed correctly via git tag or gitk.
- Then, push it via git push --tags.
- Now create the final tarball via make distcheck as described above, and upload it.
- In case of a client program (sigrok-cli / PV), create all pre-built binaries, upload them and make them available on the wiki for future reference.
- Announce the new release in the blog and on the mailing list.