Release procedure

Poul-Henning Kamp edited this page Sep 17, 2018 · 21 revisions

Release time schedule (rough)

  • The merge window for a new release is usually around a month.
  • At the end of the merge window, the first beta release will be tagged.
  • The beta release starts a 14 day long beta period. This may be extended if the betas needed significant improvement.
  • Minor (forgotten) patches may be added early on in the beta period. No code changes towards the end of the period.
  • Usually there are 2-3 betas before a release.

On some occasions technology preview (tp) releases have been made. These are pre-beta and for the early adopters.

Source release steps

  • All releases are cut of a branch, so we have it available should a CVE 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.

  • 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 y.x.z" message.

  • Do a complete rebuild and distcheck: ./autogen.sh && make distcheck

  • Push the changes, and make sure that the VTEST & Travis 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.

  • Download the release tarball from the right -src job in jenkins and use that from now on.

  • Add the tarball to repo.v-c.o: scp varnish-x.y.z.tar.gz repo.varnish-cache.org:/srv/repo.varnish-cache.org/www/source/ ssh to repo.v-c.o and do sha256sum varnish-x.y.z.tar.gz >> SHA256SUM in the source/ folder.

  • Make sure that the tarball is world readable. chmod 0644 varnish-x.y.z.tar.gz

  • Make a GPG signature of SHA256SUM with the repo GPG key. Put the signature file back as SHA256SUM.gpg in the source/ folder. This is done on a different server (script in ~lkarsten) and not documented publicly.

  • Add the release to www.varnish-cache.org in homepage.git. index.rst, docs/index.rst, releases/index.html and _template/navbar

  • Add the release to tools/0200 for automatic doc-build on homepage (ask phk)

  • 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!

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.