Developers/Release 0.8.0

This is an attempt at a checklist for the "next release" - as of 2023/10, for sigrok-cli this would be either 0.7.3 or 0.8.0 (maybe the latter would be more appropriate given that 0.7.2 was over 2 years ago ?). Other subprojects have different numbers e.g. last libsigrok was 0.5.2 .

Most of this is intended to expand on the main release guidelines here https://sigrok.org/wiki/Developers/Release_process

•   Get the blog to work

• what platforms "must work" ?
  • linux is the most tested based on IRC traffic, but maybe we can explicitly list distros to test ?
  • win : would be nice to have a list of people we can ping to get them test a build
  • osx : no idea, few users (see https://github.com/sigrokproject/sigrok-util/pull/16 ,)
  • *BSD : no idea, no user reports in IRC

• what currently open issues should be considered "blockers" for a release ?
  •  (Done) PyEval_InitThreads() deprecated in Python 3.13 see https://bugzilla.redhat.com/show_bug.cgi?id=2245598
  •  Possibly some other Python2 / 3 compatibility and deprecation issues ?
  •  random weird issues that always seem to come from Win* users running weird combinations of hardware / firmware, mostly USB ?
  •  -flto can break builds if driver list gets optimized out - see https://sigrok.org/bugzilla/show_bug.cgi?id=1433 , https://bugs.launchpad.net/ubuntu/+source/libsigrok/+bug/2025248

• what external projects depend on sigrok components or bindings ? does it actually matter ?
  • Pulseview
  • smuview

Transports (this would be better presented in a matrix format with feature vs OS) :

• serial (native/USB-CDC)
• USB (non-serial)
• USB
• TCP/IP
• GPIB (probably just linux ?)
• VXI ?

Checklists copied from the template:

libserialport-0.2

•   Check if all relevant PRs are merged.
•   Check the mailing list for relevant patches.
•   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.
  •   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.
•   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. (see https://sigrok.org/gitweb/?p=libserialport.git;a=commit;h=3fcdc9f7d5aa9bbae3041d80ab50b83e9bef182d )
  •   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.
•   Announce the new release in the blog and on the mailing list.

libsigrok

•   Check if all relevant PRs are merged.
•   Check the mailing list for relevant patches.
•   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.
  •   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.
•   Announce the new release in the blog and on the mailing list.

libsigrokdecode

•   Check if all relevant PRs are merged.
•   Check the mailing list for relevant patches.
•   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.
  •   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.
•   Announce the new release in the blog and on the mailing list.

sigrok-firmware

•   Check if all relevant PRs are merged.
•   Check the mailing list for relevant patches.
•   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.
  •   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.

sigrok-cli

•   Check if all relevant PRs are merged.
•   Check the mailing list for relevant patches.
•   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.
  •   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.

PulseView

•   Check if all relevant PRs are merged.
•   Check the mailing list for relevant patches.
•   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.
  •   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.