release: Release tarballs? How to sign releases? #1175

1. 
   real-or-random commented at 11:10 pm on December 12, 2022: contributor

   Some things that popped up during the 0.2.0 release:

   • Which tarball should we us as official release in the future?
     • github or
     • locally run git archive
     • make dist (diff should be just ci, and dotfiles)?
   • Sign the tarball and add the sigs to the release?

   Some considerations:

   • github tarball is simply and easy to refer to by tag. Tarballs and links are created automatically
   • git archive may be nice because it can be recreated locally. But then, if we want all maintainers to sign the tarball, we need to make sure it’s deterministic.
   • make dist does not seem to be a good choice. It’s a bit silly to not include files like .gitignore and .cirrus.yml. I mean this is for devs of the library, you would want to have these files. And this method depends on the build system and we want to support more than one build system in the future. (And this would raise questions like “should the autotools tarball include cmake files?” in the future.)
2. real-or-random added this to the milestone stable release (1.0.0-rc.1) on Dec 12, 2022
3. real-or-random removed this from the milestone stable release (1.0.0-rc.1) on Mar 8, 2023
4. real-or-random added this to the milestone 0.3.1 (or 0.4.0) on Mar 8, 2023
5. 
   real-or-random commented at 10:19 pm on March 8, 2023: contributor

   github tarball is simply and easy to refer to by tag. Tarballs and links are created automatically

   This is what we’ve done for 0.2.0 and 0.3.0.

   Sign the tarball and add the sigs to the release?

   We should consider this before the next release, and document the result in the process document. This will resolve this issue.

6. 
   hebasto commented at 1:31 pm on April 13, 2023: member

   What about using of CMake’s CPack module:

    0--- a/CMakeLists.txt
    1+++ b/CMakeLists.txt
    2@@ -229,6 +229,18 @@ if(SECP256K1_BUILD_EXAMPLES)
    3   add_subdirectory(examples)
    4 endif()
    5 
    6+set(CPACK_SOURCE_GENERATOR TBZ2 TGZ TXZ)
    7+set(CPACK_SOURCE_IGNORE_FILES
    8+  \\.git/
    9+  build/
   10+  ci/
   11+  \\.cirrus\\.yml
   12+  \\.gitattributes
   13+  \\.gitignore
   14+)
   15+set(CPACK_VERBATIM_VARIABLES YES)
   16+include(CPack)
   17+
   18 message("\n")
   19 message("secp256k1 configure summary")
   20 message("===========================")
   

   ?

   Here is an example of usage:

   0$ cmake -S . -B build
   1$ cmake --build build --target package_source
   2$ ls -lh build/*Source.tar*
   3-rw-rw-r-- 1 hebasto hebasto 2.2M Apr 13 14:24 build/libsecp256k1-0.3.2-Source.tar.bz2
   4-rw-rw-r-- 1 hebasto hebasto 2.5M Apr 13 14:24 build/libsecp256k1-0.3.2-Source.tar.gz
   5-rw-rw-r-- 1 hebasto hebasto 2.2M Apr 13 14:24 build/libsecp256k1-0.3.2-Source.tar.xz
   

7. 
   real-or-random commented at 9:53 am on April 20, 2023: contributor

   What about using of CMake’s CPack module

   I wasn’t aware of that one. I think that’s yet another option, but I don’t think it’s any better than git archive for our use case.

   I lean towards keeping the github tarball. It’s the same for everyone, and if we want to sign it, we can still verify its integrity by checking the files inside (okay, modulo malicious polyglots etc…)

8. 
   romanz commented at 5:07 pm on April 20, 2023: contributor

   Not sure, but https://github.com/orgs/community/discussions/45830 may be an issue…
9. 
   real-or-random commented at 5:10 pm on April 20, 2023: contributor

   Not sure, but github.com/orgs/community/discussions/45830 may be an issue…

   Oh okay, this makes git archive much more interesting…

10. 
    hebasto commented at 10:10 pm on April 21, 2023: member

    Not sure, but github.com/orgs/community/discussions/45830 may be an issue…

    Oh okay, this makes git archive much more interesting…

    See #1287.

11. real-or-random renamed this:
    release: Release tarballs?
    release: Release tarballs? How to sign releases?
    on May 12, 2023
12. jonasnick removed this from the milestone 0.3.2 (or 0.4.0) on May 12, 2023
13. 
    real-or-random commented at 4:42 pm on November 4, 2024: contributor

    We should revisit this before the next release.

    Whatever we decide on, we should update the release process to include a cursory manual inspection of the release tarball (are all aux/docs files present, etc.).

14. real-or-random added this to the milestone 0.6.1 on Nov 4, 2024
15. real-or-random added the label meta/development on Nov 4, 2024
16. real-or-random added the label release on Nov 4, 2024

Contributors
real-or-random hebasto romanz

Labels
meta/development release

Milestone
0.6.1