Skip to content

Release procedure

Jump to bottom Edit New page
Martin Blix Grydeland edited this page Mar 17, 2021 · 52 revisions

Release time schedule (rough)

  • There are two major (x.y.0) releases per year, around March 15th and September 15th
  • The whole months of March and September are freeze periods
    • Nothing should be pushed directly except documentation or purely cosmetic changes
    • Actual changes should be shelved as pull requests but may be merged for the release
  • At the end of a freeze period we put the version back to trunk on the master branch
    • We can kick off trunk release notes right away: git cherry-pick b2f5cf3c1d75f5ab72df40de87c0ddbab6639a35 (with a minor conflict to solve)

Preparing the documentation

This document assumes that the doc/changes.rst, doc/sphinx/whats-new/changes-CURRENT.rst and doc/sphinx/whats-new/upgrading-CURRENT.rst files are already updated for the next release in trunk, using -CURRENT as the placeholder for references to what will become the next release.

x.y.0 Source release steps

  • All x.y.0 releases are branched out from trunk to a branch called 'x.y'. All release preparation is done on that branch. The release itself will be tagged on that branch.
    • git checkout -b x.y
  • If you use multiple git checkouts, make sure you do a git pull initially so you don't miss any commits pushed elsewhere.
  • Update doc/changes.rst, and change 'CURRENT' to the new release number.
    • Run rst2html --halt=2 changes.rst >> /dev/null to detect syntax errors before commiting. (they will fail make distcheck)
  • Edit doc/sphinx/whats-new/changes-CURRENT.rst and doc/sphinx/whats-new/upgrading-CURRENT.rst
    • Rename the files to the correct *-x.y.rst names for the new version.
    • Edit the files changing any -CURRENT references to -x.y references
    • Edit doc/sphins/whats-new/index.rst -CURRENT references to -x.y references
  • Update etc/devicedetect.vcl to the upstream devicedetect VCL
  • Commit this file under an "Updating devicedetect.vcl to upstream" message.
  • Update configure.ac with the new version number and possibly the Copyright year.
  • Update lib/libvarnish/version.c copyright year
  • Update the "Via:" header in cache/cache_req_fsm.c
  • Update version of vrt.h as applicable.
  • Update the copyright years in the 'varnishd -V' example in doc/sphinx/index.rst to match reality
  • Commit these files under a "Prepare for x.y.z" message.
  • Do a complete rebuild and distcheck: ./autogen.des && make distcheck
    • The resulting varnish-x.y.z.tar.gz tarball is the release
  • Tag the release
    • git tag -a -m "Releasing x.y.z" varnish-x.y.z HEAD
  • Create a merge commit with the release changes, bringing all the release changes back into trunk, everything except the version change in configure.ac. This puts the release tag back into the trunk timeline, making it visible for git queries for what releases contain a given commit.
    • git checkout master
    • git merge --no-ff --no-commit --edit varnish-x.y.z
    • Edit configure.ac setting the version back to trunk
    • git commit
  • Push the release branch and release tag to the repository
    • git push -u origin x.y:x.y
    • git push origin varnish-x.y.z
  • Push the trunk changes to the repository
  • Switch to the homepage git repository, inside the R1/source/ directory and copy varnish-x.y.z.tar.gz as varnish-x.y.z.tgz in the releases/ directory.
  • Add the release to www.varnish-cache.org in the homepage repository:
    • index.rst
    • releases/index.rst
    • releases/relx.y.z.rst
    • docs/index.rst
  • Create a pull request with the homepage changes for the release.
  • Add the release to tools/0200 for automatic doc-build on homepage (ask phk)
  • Once merged, send announcement email to varnish-announce@. This Email should contain link to the tarball, the SHA256 of the tarball and a link to the changelog. The email needs to be approved in your mailman web interface: https://www.varnish-cache.org/lists/mailman/admindb/varnish-announce

Deploying packages

We currently make official packages for 64bit EL6 and EL7, as well as a set of Ubuntu and Debian releases.

The packaging scripts and shell scripts to do the builds are all in https://github.com/varnishcache/pkg-varnish-cache/ . Builds are done using mock on el6/el7 and under sbuild for Ubuntu/Debian builds. Release builds are normally built using a few jobs on VS' Jenkins server: https://jenkins.varnish-cache.org/

Any intermediate or development builds should be done using the same scripts in the terminal on a development machine.

Prerequisite: Tarball of new release must be on https://repo.varnish-cache.org/source/ including listed in SHA256SUM with a valid signature.

Build jobs are:

They need parameters to run builds, primarily RELEASENUMBER (ie. 4.0.3 or 4.1.2). RPM jobs also need RPMRELEASE, which is the x in 4.0.3-x. We don't keep package changelogs. DEBVERSION is currently asked for, but not used.

If the packages does not build, clone the pkg-varnish-cache repo and figure out why in a terminal. Life is short, don't spend time clicking "build now".

When the packages have been built, it is time to run the deploy jobs. These will get the artifacts built by the previous jobs, sign them and upload to https://packagecloud.io/varnishcache/

All done!

Add a custom footer
Add a custom sidebar

Clone this wiki locally