Skip to content

Release procedure

Jump to bottom Edit New page
Dridi Boukelmoune edited this page Sep 15, 2020 · 52 revisions

Release time schedule (rough)

  • There are two major 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

Source release steps

  • All x.y.0 releases at tagged on the master branch. We branch x.y off that tag, so we have it available should a CVE or VSV need patching. (Also needed for homepage doc-building)

  • 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 add a new section for the new release.

    • Run rst2html --halt=2 changes.rst >> /dev/null to detect syntax errors before commiting. (they will fail make distcheck)
    • Writing a changelog that is both exact and understandable for non-devs isn't easy. Consider running the draft by #varnish-dev and get feedback.

  • For x.y.0 releases, check that doc/sphinx/whats-new/changes-x.y.rst and doc/sphinx/whats-new/upgrading-x.y.rst are present and complete.

    • Also check that neither doc/sphinx/whats-new/changes-trunk.rst nor doc/sphinx/whats-new/upgrading-trunk.rst are present.

  • 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

  • Push the changes, and make sure that the VTEST, Travis CI and Circle CI jobs (both source and packaging) build successfully.

  • If all jobs pass, you are ready to tag the release. git tag -a varnish-x.y.z with commit message "Releasing x.y.z." git push origin varnish-x.y.z (it is not a good idea to push with --tags) adding such a tag does not alter the commit id, so you can use the tarball already made in jenkins.

  • The release tarball should have been created after the "Prepare for x.y.z" commit, this is important since it contains the commit hash visible in various places like panics or CLI banners. If that's not the case, do a complete rebuild and distcheck again on the commit that got tagged.

  • 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