Releases

The latest stable release of vg can always be found at: https://github.com/vgteam/vg/releases.

Release schedule

vg aims to make a new release available every six weeks.

The next release, 1.77.0, is scheduled for September 7, 2026.

• Release Issue
• Release Milestone
• Draft Changelog

Versioning

vg currently does not implement semantic versioning. We do try to minimize breaking changes but there are no guarantees in place.

We do try to maintain a semantic-like naming scheme for releases (e.g. the normal release after 1.7.0 is 1.8.0).

Docker

The vgteam docker register also receives a new docker image when a release is cut. These live at quay.io/vgteam/vg.

Before a release

1. Check that all unit and integration tests (both Travis and GitLab) have been ran.
2. Make note of any breaking changes (e.g. deprecated functions, new submodules, additional dependencies, etc) in the release issue.

Release process

To cut a new release:

1. Make sure CI has passed for the current mainline vg commit (or at least has not failed for reasons you can't explain). Extra CI tests run after PR merges; make sure those have passed before tagging the release.
2. 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)
3. Produce a buildable source tarball, containing code for vg and all submodules, and upload it to the release. You should actually use a fresh clone as shown for this step; we will delete it later.

   mkdir source-tarball
   cd source-tarball
   git clone 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"
   

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

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

5. Delete the repository after a successful tarball build.

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

6. Build and upload a static Linux binary (/bin/vg file) for the release (Mac OS X can't build static binaries). Do this from an existing vg clone.

   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
   # You may want to run the test on a different system than you built the binary
   bin/vg test
   

7. 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.
8. Clear the draft changelog for the next release
9. Create a milestone for the next release here, named vX.Y+1.Z, due in 6 weeks.
10. 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.
11. Update this wiki page with the next release version, date, issue, and milestone.
12. 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 multi-arch container manually. You will need to have a working docker command (for which you may need to talk to your system administrator), and a Quay account that has been granted access to the https://quay.io/repository/vgteam/vg repository. You will also need to be in an existing vg clone.

    docker login quay.io
    
    VG_VERSION="vX.Y.Z"
    
    git checkout ${VG_VERSION}
    git submodule sync
    git submodule update --init --recursive
    make clean
    make version
    
    docker buildx create --use
    docker buildx build --platform="linux/amd64,linux/arm64" --build-arg THREADS=8 --target run -t quay.io/vgteam/vg:${VG_VERSION} -f Dockerfile --push .
    docker buildx build --platform="linux/amd64,linux/arm64" --build-arg THREADS=8 --target run -t quay.io/vgteam/vg:latest -f Dockerfile --push .
    

13. 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}"
    

14. Edit the release and mark it as the latest release.
15. Update the manpage wiki to agree with the release code. First, make sure you have ssh key access set up for Github so you can push to the vg repository (and thus its associated wiki repository). Then, from an existing vg clone:

    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
    

16. 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: 🧪🧬🖥️
17. Close the previous release issue, and the previous release milestone in the milestone list.

References

• Information on tag finding with Git