Release vg v1.75.0

[adamnovak]

1. Create a new release on Github
   1. Look up the next scheduled codename in version.cpp. If we have run to the end of the list of codenames, quickly PR some more to master.
   2. Tag it vX.Y.Z
   3. Title it vg X.Y.Z - Codename Here
   4. Mark it as a prerelease
   5. Publish it (which tags the commit and kicks off the Docker build on our Gitlab)
2. Produce a buildable source tarball, containing code for vg and all submodules, and upload it to the release.

   mkdir source-tarball
   cd source-tarball
   git clone --recursive https://github.com/vgteam/vg.git
   cd vg
   git fetch --tags origin
   LATEST_TAG="$(git describe --tags `git rev-list --tags --max-count=1`)"
   git checkout "${LATEST_TAG}"
   git submodule update --init --recursive
   make version
   (cd deps/htslib && make htscodecs/htscodecs/version.h)
   rm -Rf .git
   find deps -name ".git" -exec rm -Rf "{}" \;
   cd ..
   mv vg "vg-${LATEST_TAG}"
   ((which pax >/dev/null && COPYFILE_DISABLE=1 pax -w "vg-${LATEST_TAG}") || tar -c "vg-${LATEST_TAG}") | gzip -c - >"vg-${LATEST_TAG}.tar.gz"
   mv "vg-${LATEST_TAG}" "vg-${LATEST_TAG}.in"
   

3. Test the tarball. If it does not build, fix it.

   tar -xf "vg-${LATEST_TAG}.tar.gz"
   (cd "vg-${LATEST_TAG}" && make -j$(nproc))
   

4. Clean up after a successful tarball build.

   rm -Rf "vg-${LATEST_TAG}" "vg-${LATEST_TAG}.in"
   

5. Build and upload a static Linux binary (/bin/vg file) for the release (Mac OS X can't build static binaries.)

   cd vg
   git remote add upstream https://github.com/vgteam/vg.git || true
   git fetch --tags upstream
   LATEST_TAG="$(git describe --tags `git rev-list --tags --max-count=1`)"
   git checkout "${LATEST_TAG}"
   git submodule sync
   git submodule update --init --recursive
   rm -f lib/libsdsl.a
   sed -i s/march=native/march=nehalem/ deps/sdsl-lite/CMakeLists.txt
   CXXFLAGS=" -march=nehalem " make -j$(nproc) static
   strip -d bin/vg
   bin/vg test
   

6. In the new release:
   1. Copy-paste the description of the previous release.
   2. Edit the links and Docker container names in the description to point to the new release
   3. Insert changes from the draft changelog
   4. List any new dependencies
   5. List any updated, moved, new, or removed submodules
      It may help to consult the log of commits since the last release, or to use a command like git diff --stat v1.58.0..v1.59.0 deps.
7. Clear the draft changelog for the next release
8. Create a milestone for the next release here, named vX.Y+1.Z, due in 6 weeks.
9. Create an issue Release vg vX.Y+1.Z for the next release on the Github issues page, using the checklist template under the Release process heading on this wiki page.
   1. Assign it to the milestone.
10. Update this wiki page with the next release version, date, issue, and milestone.
11. Gitlab is responsible for building multi-arch (ARM and x86) Docker releases. Make sure that the production-build-job on Gitlab succeeded in the Gitlab CI pipeline for the correct tag of vg. If something went wrong, you can build and push the container manually for your current architecture only:

    VG_VERSION="vX.Y.Z"
    
    git clone --recursive https://github.com/vgteam/vg.git
    cd vg
    git checkout ${VG_VERSION}
    git submodule sync
    git submodule update --init --recursive
    make version
    docker pull mirror.gcr.io/library/ubuntu:20.04
    docker build --target run -t quay.io/vgteam/vg:${VG_VERSION} -f Dockerfile .
    docker build --target test -f Dockerfile .
    
    docker logout quay.io
    docker login quay.io
    docker push quay.io/vgteam/vg:${VG_VERSION}
    docker logout quay.io
    

    See also this issue for building multi-arch Docker images manually.
12. Once the Docker build is complete, obtain the ARM64 static binary from the container, and upload it to the release.

    VG_VERSION="vX.Y.Z"
    IMAGE_ID="quay.io/vgteam/vg:${VG_VERSION}"
    docker pull --platform linux/arm64 "${IMAGE_ID}"
    CONTAINER_ID="$(docker create --platform linux/arm64 "${IMAGE_ID}")"
    docker cp "${CONTAINER_ID}:vg/bin/vg" "./vg-arm64"
    docker rm "${CONTAINER_ID}"
    docker rmi "${IMAGE_ID}"
    

13. Edit the release and mark it as no longer a pre-release, to make it the latest stable release.
14. Update the manpage wiki to agree with the release code:

    git fetch --tags origin
    LATEST_TAG="$(git describe --tags `git rev-list --tags --max-count=1`)"
    git checkout "${LATEST_TAG}"
    git submodule update --init --recursive
    make -j$(nproc)
    cd doc/wiki
    git remote add upstream git@github.com:vgteam/vg.wiki.git
    git fetch upstream
    git checkout upstream/master
    git branch -D wiki-manpage
    git checkout -b wiki-manpage
    (cd ../.. && python3 doc/vgmanmd.py >doc/wiki/vg-manpage.md)
    git add vg-manpage.md
    git commit -m "Update manpage for vg ${LATEST_TAG}"
    git push upstream wiki-manpage:master
    cd ../..
    git submodule update --init --recursive
    

15. Contact Rose Miyatsu at UCSC by e-mail to promote the release. Send a couple sentences about the milestones reached in the release, a link to the release on Github, and the vg logo or any more relevant image available.
    1. Include these relevant Bluesky handles: @benedictpaten.bsky.social @adamnovak.graphs.vg @thinks.lol @jltsiren.bsky.social @xian-chang.bsky.social @jmonlong.bsky.social and topic emojis: 🧪🧬🖥️
16. Close the previous release issue, and the previous release milestone in the milestone list.