Building a TEI Release


Contents

This document aims to provide a set of detailed instructions enabling a "release technician" (the Council member tasked with implementing a new release of the TEI) to prepare for and manage the release process. It assumes that the new packages will be taken from one of the Jenkins servers rather than being built locally by the release technician. This is easier and more reliable, because we ensure that the Jenkins servers are regularly updated and are correctly configured to build the TEI products.

Packages on Sourceforge and GitHub

The TEI maintains a number of distinct packages on Sourceforge and GitHub. The main repository for the developing P5 Guidelines and associated schemas is on SourceForge, and the TEI Stylesheets and the code for the Roma web application can be found on GitHub.

Two other packages, I18N, which provides input for the internationalization utilities used in producing P5, and TEIOO which provides P5 support for Open Office, are also maintained, but unpublished.

The rest of this section describes how to make a new release for the main P5 package, but similar procedures apply to the others. The instructions assume you are working on a Linux or MacOSX system with a command line, and know (more or less) how to do basic command-line operations such as running scripts and logging into a server with ssh.

What you will need before you start

  1. An account on SourceForge, and committer privileges over the TEI repository. If you have ever committed a change to the TEI repository, you should have all the required permissions.
  2. Shell access on the TEI SourceForge project. Contact one of the admins to have this turned on. Normal committers don't have shell access.
  3. The release manager will need SSH login access to the tei account on the tei-c.org server. This involves two steps:
    • Generate an SSH key pair (if you don't have one already). If this is new to you, look at https://en.wikipedia.org/wiki/Ssh-keygen.
    • Send the public key to the Council Chair, who will forward it on to the system administrator.
    Make sure you get this set up well in advance of the release day, and make sure you can ssh tei@tei-c.org successfully.
  4. Some familiarity with the two TEI Jenkins Continuous Integration Servers (their URLs are below). Take a little time to watch them work, and see how a commit to the SourceForge SVN causes them to start building TEI packages. There are three specific build jobs associated with P5, and they run in a fixed sequence.
  5. A nickname for irc.freenode.net, so you can log into #tei-c channel for live help from other Council members.
  6. Several hours of time. You won't be busy all the time, but the process from beginning to end takes several hours, especially if something goes a bit wrong and you have to retrace your steps. It's best to start first thing in the morning, and prepare to be busy all day.
  7. A copy of the public key that will enable you to sync the release zip with SourceForge.
    • log in to the tei server (ssh tei@tei-c.org -- this requires that you've completed the other public key step above).
    • cat ~/.ssh/id_rsa.pub and copy the contents to the clipboard.
    • paste the result into a text editor and remove any linebreaks added by the terminal.
    • copy-paste the result into https://sourceforge.net/account/ssh
    What this does is to enable you (when logged in as tei to tei-c.org) to connect to SourceForge (as your SF user) to upload the release files.
  8. Test it by trying to log into SourceForge via ssh from the tei-c.org server:
    ssh sfuser,tei@frs.sourceforge.net
    where "sfuser" is your SourceForge user name. You should not see a prompt for a password (because of the ssh keys you have set up). Instead, you should immediately see ‘Welcome! This is a restricted Shell Account. You can only copy files to/from here.’ If you see this, then everything is set up correctly.

Step-by-step instructions

  1. Ensure that P5/ReleaseNotes/readme-X.X.X.xml has been written
    Normally, this will have been created by the TEI Council chair at the point when the repository moved from its "alpha" stage to "beta", so you should not have to do this, but in case you do:
    • Confirm the version number for the new release in consultation with Council. TEI version numbers are based on the system used by the Unicode Consortium but with the first digit for major changes, the second for schema-changing revisions, and the third for non-schema-changing revisions. When the first or second digit is incremented, the following digit or digits is set to zero. During initial development, the version number is followed by "alpha"; during the pre-release checking stage, it's followed by "beta"; and when the release takes place, "beta" is removed and the version number has only digits and periods.
    • Create the new file by cloning a previous one.
    • Consult the SourceForge SVN log to check for all the significant changes since the last release. You can do this by opening a terminal in the root of a working copy of the TEI repository and running:
      svn log -r {2011-12-12}:HEAD
      where the date is that of the previous release.
    • Add the new file into the repository with svn add. You may also want to set its svn properties. Make sure it has an SVN header block immediately after the XML declaration, and if it doesn't, copy and paste from another file. Then run svn propset svn:keywords 'LastChangedRevision LastChangedBy Id LastChangedDate HeadURL' filename.xml.
  2. Edit the P5/VERSION file to the correct number
    This file consists only of the bare version number, followed by "alpha" or "beta":
    2.8.2beta
    For the release process, you need to remove the letters from the end, leaving a pure version number:
    2.8.2
    This changes the release from beta (or possibly alpha) to the actual release version number. After the release process has been completed, the number should be incremented appropriately, and "alpha" added to the end of it:
    2.8.3alpha
    signifying that the versions built subsequent to the release are now in the alpha stage.
  3. Announce a temporary freeze on commits to the TEI Technical Council mailing list
    This ensures that no-one else will commit a change that triggers rebuilds on the Jenkins servers.
  4. In the trunk/P5 directory, do
    make changelog
    to generate an updated ChangeLog file.
  5. Commit your changes to SVN, and watch Jenkins build P5 for you
    This should be the final commit for this version, and it will trigger the Jenkins servers into rebuilding the TEI packages. This is where you'll find the Jenkins servers: And now you wait, and watch the Jenkins servers build the packages. This can take a couple of hours, so be patient. Both of the Jenkins servers should behave identically, and they should both build all three TEI packages successfully.
  6. Ensure all changes have been committed, built, and successfully passed tests on the continual integration server
    When all builds have completed on both servers, click on the job number of the last build for each of the three TEI jobs to make sure that it was triggered by the commit that you made in the previous step (you should see your own commit message on the build page). Make sure that all builds were successful (they should have green balls next to them).
  7. Log into TEI server and run the tei-install.sh script:
    ssh tei@tei-c.org
    cd ~/private/P5/Utilities (this is where the scripts are)
    svn update (this updates the local copy of the subversion repository because the scripts in that the release technician is using are in subversion. You should not be editing these scripts locally on tei-c.org instead, edit them and commit them to subversion. Wherever possible there should be no special local magic files.)
    ./tei-install.sh --package=TEIP5 --version=X.X.X --sfuser=username
    Replace the Xs with your release version. Supply your SourceForge user name, and type your password when prompted. By default, the script will pull the release package from the Oxford Jenkins server, but you can supply the URL of the other server if necessary; read the script to see the details. Make sure the script completes successfully.
  8. Run the tei-database-rebuild.sh script (on tei-c.org)
    This will update the XML database containing TEI documentation on the TEI server:
    ./tei-database-rebuild.sh
    This is the database used by Roma, so this operation will ensure that Roma is using the new version.
  9. Check the TEI website and all downloadable files are displaying the correct version
    Everything should now be done, so go to the newly released version on the TEI site and browse the Guidelines. Check that your version number is displayed in the footer of the page, and check that at least one change made since the last release is being reflected online. Visit Roma at http://www.tei-c.org/Roma/ , and generate a simple schema to confirm it works, and check that the version number is right in the footer. Also, go to SourceForge and make sure that the main Download button links to your package.
  10. Make your release the default downloadable version from Sourceforge
    Go to the SourceForge site:
    https://sourceforge.net/projects/tei/files/TEI-P5-all/
    log in, and click the information button on your new release. Make it the default download for all operating systems.
  11. Update SVN tags on SourceForge
    Every time a new release is made, a "tag" is created consisting of a complete copy of the P5 tree at release time. You can do this from the command line on your own computer. This is how to do it:
    svn copy -m "Tagging the X.X.X release of P5." https://svn.code.sf.net/p/tei/code/trunk/P5 https://svn.code.sf.net/p/tei/code/tags/P5_release_X.X.X
    where X.X.X is your new release. Supply your SourceForge credentials when prompted.
  12. Inform the Debian Package Maintainer of the new release
    The Debian repository can only be updated by its maintainer (Sebastian Rahtz), so let him know that your release is done, so he can grab the new packages and add them to the repository.
  13. Update the list of Previous releases of P5
    If you have editing privileges on the OpenCMS system on tei-c.org, add the new release to the top of the release table. If not, ask one of the other Council members who does (currently James Cummings and Martin Holmes) to make the change.
  14. Update the oXygen-ready distribution of TEI.
    This involves building the new package of oxygen-tei, and then updating the distribution file on the TEI server so that the oXygen software knows about the new release. This step may have to be handed off to one of the oxygen-tei developers if you do not have all the permissions required.
    • Check that you have ant (at least version 1.8) installed on your machine.
    • Make sure you know your Google SVN password (not the same as your GMail password).
    • Check that the latest versions of the TEI Stylesheets and TEI P5 packages are available for download from the SourceForge Files section, since the oxygen-tei update/upload script retrieves them from there.
    • If you have write permission on the Google Code project, you can check out the source from http://code.google.com/p/oxygen-tei/ to your local system and run the shell script update-and-upload.sh. Otherwise, ask one of the maintainers (currently Sebastian Rahtz, James Cummings, Syd Bauman or Martin Holmes) to do this for you. If you're one of the people doing it, you'll first need to svn update your oxygen-tei local copy, then run this:
      ./update-and-upload.sh --xslversion=6.18 --teiversion=2.2.0
      where the version numbers are taken from the relevant VERSION files in the TEI SVN trunk at http://sourceforge.net/p/tei/code/HEAD/tree/trunk/P5/VERSION (for P5), and the GitHub repository at https://github.com/TEIC/Stylesheets/blob/master/VERSION (for the Stylesheets).
    • Now you need to update the file which the oXygen software uses to update its frameworks. Log into the TEI server as tei@tei-c.org, and then:
    • cd to /var/www/vhosts/tei-c.org/projects/tei/web/Vault/P5/
    • cp x.x.x/updateSite.oxygen y.y.y/updateSite.oxygen (where x.x.x is the version number of the previous release, and y.y.y is that of the new release you just made).
    • Edit y.y.y/updateSite.oxygen in your preferred text editor.
    • Change xt:version to match the new version number of the plugin.
    • Change xt:location to point to the SourceForge download location for the zip (substituting the correct version numbers of P5 and the Stylesheets):
      http://downloads.sourceforge.net/project/tei/tei-oxygen/teioxygen-2.6.0-7.9.0.zip
  15. Inform the TEI Technical Council Chair so they can announce the release
    Once you are sure that everything is working correctly, inform the Council Chair. They will announce the release to the TEI-L mailing list, including the text of P5/ReleaseNotes/readme-X.X.X.xml in plain text form (which can be generated using the "readme" profile for teitotxt), and place an announcement on the Text Encoding Initiative Newsfeed blog in the category of 'News'. They will also update the table of previous releases at http://www.tei-c.org/Guidelines/P5/index.xml#previous.
  16. Lift the freeze on committing changes to the repository
    Write to the TEI Council list and let them know that they can once again start committing changes to the repository.
  17. Inform the Stylesheets maintainer that a new release has been completed
    The TEI Stylesheets project depends on the current release of P5, and when a new release appears, the tests which are part of the stylesheet build process will probably fail, breaking the build. The maintainer will have to change the tests in accordance with the new release of P5. This can only be done after the release process has been completed. The current Stylesheets maintainer is Sebastian Rahtz.
  18. Increment the build number for the next release cycle
    After the release process has been completed, the release number in the repository needs to be updated. Edit the P5/VERSION file to the correct number. This file contains nothing except the bare version number. It should be incremented appropriately, and "a" or "alpha" added to the end of it, so if for example the release was number 2.8.2, you would change the number in the file to:
    2.8.3alpha
    signifying that the versions built subsequent to the release are now in the alpha stage.