Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
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 pullinitially so you don't miss any commits pushed elsewhere.
doc/changes.rst, and add a new section for the new release.
rst2html --halt=2 changes.rst >> /dev/nullto 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.
configure.acwith 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.zwith 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 >> SHA256SUMin 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
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/