User Tools

Site Tools


dev:release_process:evergreen:2.8

Rolling an Evergreen Release

¡This is a work in progress. It will grow and change!

Install packager dependencies

  • Install the packager dependencies using the Evergreen installer makefile:
# sudo make -f Open-ILS/src/extras/Makefile.install <os>-packager
$ sudo make -f Open-ILS/src/extras/Makefile.install ubuntu-trusty-packager

Update relator codes (requires commit bit)

$ perl build/tools/relator_map > Open-ILS/src/templates/opac/parts/relators.tt2
# if 'git status' shows changes, commit them.
$ git commit -sm "Updating relator codes for 2.8" Open-ILS/src/templates/opac/parts/relators.tt2

Prepare release notes (for major version bumps only)

=> See also the Release Notes Process for DIG Release Coordinator

  • Cut a new release branch (such as rel_3_7):
git checkout -b rel_3_7 master
  • Update the version in the antora configuration
$ vi docs/antora.yml

edit 'latest' -> '3.7'

  • Create release notes
$ cd docs/RELEASE_NOTES_NEXT
$ ./create_release_notes.sh -r 2_8
  • Remove 2.8-specific files from docs/RELEASE_NOTES_NEXT.
    • Running the following in the docs/RELEASE_NOTES_NEXT directory should work:
$ find . -mindepth 2 -name '*.txt' -exec git rm {} \;
$ find . -mindepth 2 -name '*.adoc' -exec git rm {} \;
  • Stage your changes and commit the release notes: `git commit -sm "3.7 release notes"`

For an alpha or beta release, this rough process is probably enough. For a real #.0 release, the resulting compiled release notes will need some TLC/cleanup.

Translations, Part 1: newpot (requires commit bit)

  • During each release starting with beta, get the latest template changes and apply them to the main branch you are working from in origin (master/rel_3_1/etc.). It is important to merge any new pot changes to origin so that Launchpad translations will get the latest strings that require translation.
    • Update pot in Evergreen
      $ cd build/i18n && make newpot
    • From the Evergreen directory, run the python script to commit any changes that do more than modify metadata
      python3 build/i18n/scripts/add_translations.py -c # use -h option for help

Translations, Part 1a: Angular Staff Client Updates (requires a POEditor account)

  • Export strings for the Angular staff client and import them into POEditor, following these instructions.

Setting up your git branch

  • Create a local working branch for the release. This will contain changes applicable to only this release, and become the release "tag":
$ git checkout -b rel_2_8_0 origin/master

Translations, Part 2: update_pofiles

  • Next, clone (or update) the translations repository in a new directory as a peer to Evergreen:
$ cd ../; 
# Clone the repository if necessary
$ bzr branch lp:~denials/evergreen/translation-export
# If already cloned, simply pull in the latest changes
$ cd translation-export; bzr pull; cd ../
  • Then, sync translated files with Evergreen. Update PO files in the appropriate branch in origin:
$ Evergreen/build/i18n/scripts/update_pofiles -l translation-export -e Evergreen
$ cd Evergreen
$ git add -A build # pick up updates
$ git commit -asm "Translation updates - po files"

Translations, Part 2a: Update Angular Staff Client Translations (requires a POEditor account)

  • Export (as xtb) any translations from the POEdtior site that have over 50% translations available and save them to Open-ILS/src/eg2/src/locale/:
$ cp ~/download/path/messages.*.xtb ./Open-ILS/src/eg2/src/locale/
$ git add -A Open-ILS/src/eg2/src/locale/
$ git commit -asm "Translation updates - xtb files"

Other version number changes

  • Edit ./Open-ILS/src/perlmods/lib/OpenILS.pm and set (e.g., for 3.1.1):
our $VERSION = '3.0101';
  • NOTE: The version string is two digits for each level after the decimal, so for example "3.0.5" would become "3.0005"
  • Commit the version change
$ git commit -asm "bumping Perl version string for 2.8"

Update server upgrade documentation

  • Replace references to base version (e.g. 2.12.1) with new version in docs/modules/installation/pages/server_upgrade.adoc (#.#.# and #_#_# versions)

Run the release builder script

  • Run the release builder script
$ export PATH=$PATH:/openils/bin
$ build/tools/make_release -x -c -v 2.8.0 -f origin/tags/rel_2_7_3
  • Additional notes on make_release options:
    • Use the -v flag when your branch name does not match the normal pattern, otherwise auto-detect works
    • Use the -j flag to point at wherever your OpenSRF javascript lib source is, if not already installed
      • -j ~/Git/OpenSRF/src/javascript/
    • Use the -c flag to make with the web client
    • The -f flag sets the branch "from" which this release this being made from, aka what was the last version of Evergreen prior to the one you're making. This guides the make_release towards creating a version-upgrade from X to Y.
    • You can add the -r option to edit the upgrade script before it goes into the tarball. This may be necessary if tables that get altered in the upgrade scripts also have updates or inserts of new data.
    • You can add the -x option to prevent the script from compiling and outputting the XUL staff client.

Generate release docs

# copy README and docs/RELEASE_NOTE_2_x.adoc to ../release/
$ cp README ../release/README_2_8
$ cp docs/RELEASE_NOTES_2_8.adoc ../release/
$ cd ../release/
# in ../release/
$ asciidoc -a toc -a numbered README_2_8
$ asciidoc -a toc -a numbered RELEASE_NOTES_2_8.adoc
# delete the originals
$ rm README_2_8
$ rm RELEASE_NOTES_2_8.adoc

Upload to web server (requires lupin access)

Move the release files into the correct download directories:

  • Previews / alphas / betas / release candidates go in /var/www/open-ils.org/downloads/previews/
  • Final releases go in /var/www/open-ils.org/downloads/
  • Install docs go in /var/www/open-ils.org/documentation/install/
  • Release notes go in /var/www/open-ils.org/documentation/release/

"Tag" Working Branch (requires commit bit)

git push origin rel_2_8_0:tags/rel_2_8_0

"Forward-port" Version Upgrade Script (and, optionally, po files updates) (requires commit bit)

If doing a final release, you will need to copy the upgrade script you created to master and your current rel_x_y branch. If you skip copying to the rel_x_y branch in particular, your next point release will be missing an upgrade script in the middle of the chain!

Announcing and recording the release

  • Update evergreen_history.txt file in history repo with release dates.
  • Release team / outreach committee make announcements following publicity checklist
dev/release_process/evergreen/2.8.txt · Last modified: 2022/11/23 14:11 by klussier

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki

© 2008-2022 GPLS and others. Evergreen is open source software, freely licensed under GNU GPLv2 or later.
The Evergreen Project is a U.S. 501(c)3 non-profit organization.