EximRelease

Exim Release Process

An aide-memoire etc - currently just trying to ensure we have all of this stuff captured...

We follow EximReleasePolicy for releases.

Except for the Security Release Process.

Each Feature/Bug Fix

• Ideally work with complete git working directory -- including the src and doc subdirectories -- to ensure a single checkin includes both the code and the documentation changes - even better if test suite changes can also be integrated.
• Update the main documentation in exim-doc/doc-docbook/spec.xfpt
• Add regression testcases for bugfixes, feature testcase for features
• If appropriate update NewStuff (in the exim-doc/doc-txt subdirectory).
• Always update ChangeLog after each change (also in the exim-doc/doc-txt subdirectory).
• Put the bugzilla reference into ChangeLog
• Use the bugzilla reference in the checkin message (updates bugzilla with the checkin details) - see BugZilla for details

Start of Development Cycle

• Update documentation with version number of next release
• Remove all changebars from documentation except the sample (around SECID1) - basically strip all .new and .wen tags and remove &new() enclosures
• If a 4.next branch was running during the RC stages of the just-done release, merge it back to the mainline and drop it from the buildfarm

When starting run-up to a release

• Reset the 4.next branch to the current master checkin
• Add 4.next to the buildfarm (exim-build-farm-server git tree; htdocs/branches_of_interest.txt). Check that krot (buildfarm server) is up to date
• (ongoing) commits you want to record but not have in this release go to 4.next (for example, new features once you've declared feature-freeze for the release)

Release Steps

• Checkout the "master" git branch
• Ensure test suite runs
• For sanity doing RCs, set shell variables eg. maj=79 rc=4
  • For full release, maj=78 oldmaj=79
  • For a security release maj=78 min=1
  • and then: name=4.${maj:?}${min:+.}${min}${rc:+-RC}${rc}
• For a full release:
  • Check version number in documentation match new release version (source is handled by the reversion script during build, using info from git)
  • Update the copyyear date (a macro near the top) in doc/doc-docbook/spec.xfpt and doc/doc-docbook/filter.xfpt
  • Update the version_copyright string in src/src/globals.c if needed.
  • Check if local_scan.h has been modified (git log) since the last time it's API version number was updated. Not all changes require an update, but it is very easy for this file to get modified without noticing
  • Check for modify dates on all source files, and update copyright year in the file header comment: vi $(git log --name-status exim-4.${oldmaj:?}..master | awk '/^M/{print $2}' | grep -v '^test/' | sort -u)
• Check that the NewStuff and ChangeLog and doc-txt/OptionLists.txt files are up-to-date
• Check if test/configure needs commit (run autoreconf in test/)
• Tag git for new release - tag format is exim hyphen version number with dots - eg exim-4.92. You must also have git sign the tag with your exim PGP id - ie git tag -u [email protected] for the tarball to be built correctly.
  • u/s for me; used git tag -s -m "Exim 4.${maj:?}${min:+.}${min}${rc:+ RC}${rc}" exim-${name:?}
• Build documentation and packages:-
  • ensure exim-website is checked out to a known location, ideally into the same directory where exim is located.
  • cd exim
  • if not first RC for this release, clean the previous website docbook files out: rm -f ../exim-website/docbook/4.${maj}/*
  • Main build (use appropriate version number):
    • release-process/scripts/mk_exim_release ${name:?} /tmp/exim-pkgs
    • files produced into /tmp/exim-pkgs directory
    • (should be already done, by mk_exim_release) Sign the tarballs: release-process/scripts/sign_exim_packages /tmp/exim-pkgs (If git configuration user.signingkey does not identify the PGP key to use, then you must specify EXIM_KEY in environ).
    • also writes website documentation sources into exim-website/docbook/${name}/ for a full release, check the front-page source file templates/web/index.xsl for text saying This is a security release and remove or comment out.
      • for a full or security release git add/commit: cd ../exim-website && git add docbook/${name} && git commit -m "Add Exim ${name}" docbook/${name}
      • contact HS to get the website published
• Ideally have limited final test before full distribution
• put tarballs and signatures up for distribution
  • for RCs in /srv/ftp/pub/exim/exim4/test/
    • for the initial RC, clear that dir first
    • for subsequent ones, clear the '00' files first
  • for a security release
    • Move last release files in the old subdirectory
    • new files to /srv/ftp/pub/exim/exim4/
  • for full release
    • Move last release files in the old subdirectory: cd /srv/www/vhosts/www.exim.org && mv 0* C* N* exim* old/
    • new files to /srv/ftp/pub/exim/exim4/
    • Unpack PDF documentation from distro tarball into the website area :- cd /srv/www/vhosts/www.exim.org && tar xvf /srv/ftp/pub/exim/exim4/exim-pdf-4.${maj:?}.tar.gz
    • Don't do the HTML docs and the exim-pdf-current link; done during (auto) update of the website
    • Unpack ChangeLog and NewStuff to /srv/ftp/pub/exim/exim4/ and make .gz versions This needs automating :-

cd; f=/srv/ftp/pub/exim/exim4;
tar -x -f $f/exim-4.${maj:?}.tar.xz exim-4.${maj}/doc/ChangeLog &&
tar -x -f $f/exim-4.${maj:?}.tar.xz exim-4.${maj}/doc/NewStuff &&
mv exim-4.${maj:?}/doc/* $f/ &&
rm -fr exim-4.${maj:?} &&
cd $f &&
gzip -9k ChangeLog &&
gzip -9k NewStuff;

• Ensure git tree (with tags) is pushed to central repo: git push --follow-tags
  • security releases should be going to a branch exim-4.${maj}+fixes
• Write announcement including changes and cryptographic checksums
  • to [email protected] and [email protected]
  • SHA256 checksums only for now; 4.80 was the last to use both SHA1 and SHA256. We'll add SHA-3 if is comes into common use. ./release-process/scripts/stats_for_email /tmp/exim-pkgs
    • Now deprecated; the signatures should be sufficient
  • mail should be signed by a key with an @exim.org uid, that has been signed by the other Exim Maintainers.
  • note that hummus requires authentication for any mail sent with a sender in the @exim.org domain
• Pimp the release or RC on social media
  • Especially for Release Candidates: we don't want to spam the announce list with these, but there are many folks who don't follow exim-users because of the volume but who are interested in trying out Release Candidates to help out
  • Tweet it. Try using an #Exim hashtag.
  • Update the Topic on the #exim IRC channel on Libera Chat
  • Consider other social media; bias towards our audience, which is computer-literate folks who run systems for themselves or employers in a federated communication system. Eg, Mastodon?
    • Bernard is doing this on Mastodon; also #exim
• If a security release
  • Update EximSecurity with details
  • Cherry-pick the fix into the master branch
  • Shuffle the items in doc-txt/ChangeLog
• Remaining steps only for full releases
  • Update wiki - at least the ObtainingExim page (link others here too)
  • Update Wikipedia version information, because we're nice like that
  • Update Bugzilla:
    • add released version to list of bugzilla versions (Edit:Products/Exim/Edit_Versions/Add)
    • disable a (or some) really old versions (Edit_versions_again/the_version/untick_active)
    • add next expected version to bugzilla milestones (Edit:Products/Exim/Edit_Milestones/Add), and make that default (button on Edit:Products/Exim page)

RC Steps

• This should be inline above
• Basically same as for release, except no update of website and ChangeLog/NewStuff distro on ftp site
• Tag has form exim-4.92-RC3
• Files should be placed in test subdirectory rather than in main distribution directory

Things to do

• Clean up the release package scripting and make it generally usable
• Script the above steps from put tarballs to ChangeLog - the file moving part can all be automated.
• Can we script the old change bar removal and new change bar generation in the documentation?
  • ./release-process/scripts/docs_strip_changebars (stdin to stdout) is a go at this, currently in 4.next. It handles .new/.wen but not &new() - and it fails to leave the initial one in place.
• Sort out website to auto-update from git (this was done via nm4's cronjob but HS is working on automation)