[Release] One click release

[kunaltyagi]

Is your feature request related to a problem? Please describe.

Releasing PCL requires effort from multiple contributors to add the binaries for different platforms. That takes time, and is difficult to trust

Expected behavior

1. Release PR is merged to master
2. Maintainer runs a pipeline and it performs a release without requiring any input (except maybe the release number)

Describe the solution you'd like

We can use the CI to generate the binaries (and source code), and the SHA2 and MD5 checksums for each artifact for different platforms. The artifacts can then be added to the GitHub release page using the API (or a CI shortcut)

TODO list:

• Create CI for compiling as Debian does for release (Add dockerfiles for testing before release #3995)
• Create CI for compiling perception_pcl, a large open-source downstream user of PCL (Add dockerfiles for testing before release #3995)
• Generate source code archives with SHA256 and SHA512 checksums (Towards one-click release #4073)
• Generate release on the release page (Towards one-click release #4073)
• Sign binaries using PGP key (needs org PGP key)
• Sign MacOS binaries properly (tracked by Sign MacOS binaries properly #3714)
• Creating Windows installers
• Creating Linux flatpack
• Creating Mac package

Describe alternatives you've considered

Manual release is not feasible in the long term. Considered and discarded.

[kunaltyagi]

Should we be creating the independent binaries as well for Linux and Windows?

[SergioRAgostinho]

This would be amazing ❤️ In personal order of priority:

1. Creating the Release on the release page
2. Windows Installer/Uninstaller
3. Linux flatpack
4. Mac package (aka installer/uninstaller)

[kunaltyagi]

Request for @PointCloudLibrary/maintainers

Can we get the steps used to create the releases as bash or powershell scripts?

[taketwo]

No Bash script this time, sorry. From my side the process always involved two PRs with a tag in between:

• 1st PR:
  • Bump version to x.x.x in CMakeLists.txt
  • Find replace all occurrences of x.x.x.99 CMake requirements in the tutorials and examples
  • Bump version off the release badge in README.md
  • Finalize changelog, fix the release date, commit
• Tag
• 2nd PR:
  • Bump version to x.x.x-dev in CMakeLists.txt

[SergioRAgostinho]

I'm not entirely sure if it's possible but let's go step-by-step here. This is our usual list of steps.

Task list

• Go through all PR for the milestone - make a check if there are open items for this milestone. python stuff
• Update Changelog - this is already done with every merge to master but it should be displayed once more to the maintainer before proceeding
• Start a release branch - I believe this actually just happens if we find that we broke something unintentionally. So in a sense, it only happens after the next step in this list.
• (If needed) Revert whatever unintentional API/ABI breakage that might have occurred in the release branch - run abi checker. It only needs to enforce that there are no issues between patch version updates. It should present to the maintainer the reports for all modules so that he/she could skim through and confirm everything is as expected.

Everything else from here onward can be automated

• Bump version to x.x.x in CMakeLists.txt
• Find replace all occurrences of x.x.x.99 CMake requirements in the tutorials and examples
• Try to build and test on all relevant platforms
• Bump version off the release badge in README.md
• Finalize changelog and fix the release date
• Tag
• Remove the release branch
• Add binaries to the GitHub release page
• Send a PR to vcpkg to update package to the new version
• Bump version to x.x.x-dev in CMakeLists.txt
• Send announcements to the mailing lists - push a new post to the website announcing new release.

That being said, PCL is becoming more and more a devops wet dream.

[kunaltyagi]

• API/ABI testing is useful for minor releases only. For the rest, it's not needed right now.
• Remove hardcoded version number from tutorial CI #4058 removes tutorials as dependent on version number. The only places with 1.10 needs to be changed are CMakeLists.txt and README.md
  grep --exclude-dir=build '[^0-9a-zA-Z.]1\.10[^0-9]' * -nr
• Is the "Try to build and test on all platforms" needed since we have CI? It would complicate the release yaml file (Side-effects include: no release possible if Apple CI starts barfing errors on it's regular schedule)

[kunaltyagi]

Part 1 Update: To release

new_verion=<INPUT_FROM_SOMEWHERE>
sed -i "s,[0-9]\+\.[0-9]\+\.[0-9]\+,${new_version}," README.md
sed -i "s,VERSION [0-9.]*),VERSION ${new_version})," CMakeLists.txt

Part 2 Update: Post release

new_version=<INPUT_FROM_SOMEWHERE>.99
sed -i "s,VERSION [0-9.]*),VERSION ${new_version})," CMakeLists.txt

Questions:

• how to create these 2 commits using the release CI?
• does the CI wait to verify these 2 commits?

Once this is figured out, we'll have the achieved almost all milestones for a 1 click release

[kunaltyagi]

Will it be ok to create and merge the PR using GitHub API without waiting for CI result?