logo_kerberos.gif

Difference between revisions of "Release engineering notes"

From K5Wiki
Jump to: navigation, search
Line 1: Line 1:
==Required manual steps==
 
  +
==Pulling up changes to release branches==
  +
  +
* For each supported release (usually the most recent and one previous release), prepare a git working copy with the krb5-X.Y branch checked out from the master repository. From the krbdev-services repository, copy githooks/hookutils.py and githooks-client/prepare-commit-msg into .git/hooks for both working copies.
  +
  +
* Check that each working copy is clean, has no unexpected extra commits, and is up to date with the master repository. Checking the output of "git status" and running "git pull" should accomplish this.
  +
  +
* At https://krbdev.mit.edu/rt/ , start a new search, add the criteria "queue is krb5", then the criteria "tags is pullup", then search. It can be useful to create a browser tab for each search result.
  +
  +
* For each release branch:
  +
** For each ticket marked for pullup to that branch:
  +
*** For each commit listed in the ticket, run "KRB5_VERSION_FIXED=X.Y.Z git cherry-pick -x COMMIT", and address any merge conflicts. X.Y.Z should be the next patch release that will be created on the release branch.
  +
*** Examine the commits any consider any possible interactions with changes made since the release branch.
  +
*** Run "make" and "make check".
  +
*** If the change isn't covered by automated tests, consider testing it by hand.
  +
* Consider pushing the updated release branches to a personal github fork integrated with Travis, and waiting for Travis to finish building and testing it.
  +
* If the pulled up changes are substantial, consider running a build and check of each release branch on krbdev-sparc-build.
  +
* Push the updated release branches to the master repository.
  +
* Remove the "pullup" tag from each ticket. This can be done in a bulk update from the search result page using the button at the lower right, or it can be done on each ticket individually from the jumbo page.
  +
  +
==Preparing releases==
   
 
===Pre-mkrel===
 
===Pre-mkrel===

Revision as of 12:51, 24 February 2017

Pulling up changes to release branches

  • For each supported release (usually the most recent and one previous release), prepare a git working copy with the krb5-X.Y branch checked out from the master repository. From the krbdev-services repository, copy githooks/hookutils.py and githooks-client/prepare-commit-msg into .git/hooks for both working copies.
  • Check that each working copy is clean, has no unexpected extra commits, and is up to date with the master repository. Checking the output of "git status" and running "git pull" should accomplish this.
  • At https://krbdev.mit.edu/rt/ , start a new search, add the criteria "queue is krb5", then the criteria "tags is pullup", then search. It can be useful to create a browser tab for each search result.
  • For each release branch:
    • For each ticket marked for pullup to that branch:
      • For each commit listed in the ticket, run "KRB5_VERSION_FIXED=X.Y.Z git cherry-pick -x COMMIT", and address any merge conflicts. X.Y.Z should be the next patch release that will be created on the release branch.
      • Examine the commits any consider any possible interactions with changes made since the release branch.
      • Run "make" and "make check".
      • If the change isn't covered by automated tests, consider testing it by hand.
  • Consider pushing the updated release branches to a personal github fork integrated with Travis, and waiting for Travis to finish building and testing it.
  • If the pulled up changes are substantial, consider running a build and check of each release branch on krbdev-sparc-build.
  • Push the updated release branches to the master repository.
  • Remove the "pullup" tag from each ticket. This can be done in a bulk update from the search result page using the button at the lower right, or it can be done on each ticket individually from the jumbo page.

Preparing releases

Pre-mkrel

  • check copyright years in project-wide stuff
  • update config.guess and config.sub from git://git.savannah.gnu.org/config.git
  • make sure you're in a build tree that's not the source tree and configured using --enable-maintainer-mode
  • make depend and commit if changed
  • regenerate manpages: (cd man && make man) and commit if changed
  • regenerate localization template (cd po && make update-po) and commit if changed
  • manually edit patchlevel.h to reflect the new release
  • manually update README
    • release dates (in major changes heading, ISO 8601 date format with hyphens)
    • changes
      • note whether bugfix release, maintenance vs current release
      • bullet list of major changes
      • minor changes = list of RT tickets fixed -- always grab a fresh list from RT when editing these!
    • contributors (RT is a good source for these)
  • make additional manpage and update-po commits with updated patchlevel.h
  • squash preceding commits so all versioning-related commits are a single commit (non-versioning changes to maintainer-mode stuff should remain separate commits)
  • git tag krb5-x.y.z-final

Running mkrel

  • path_to_mkrel/mkrel --repository $YOUR_SOURCE_TREE krb5-x.y.z-final krb5-x.y.z
  • manually inspect output for versioning and correctness
    • HTML docs
    • PDF docs
    • patchlevel.h as modified by mkrel
  • push to authoritative repository
  • rerun mkrel against the authoritative repository: path_to_mkrel/mkrel krb5-x.y.z-final krb5-x.y.z

Post-mkrel

  • PGP sign
  • generate branded HTML docs
    • HTML_LOGO=.... make html
    • we don't ship the branded (with logo) docs because the logo is an MIT trademark
  • edit web pages
  • send announcement to kerberos-announce