User Tools

Site Tools


dev:release_process:evergreen:2.8

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
dev:release_process:evergreen:2.8 [2016/02/19 09:24]
dyrcona Fix find command arguments
dev:release_process:evergreen:2.8 [2020/09/17 12:31] (current)
gmcharlton add a todo re the Angular staff interface
Line 4: Line 4:
  
  
-  ​* Install the **packager** dependencies using the Evergreen installer makefile: ​(PENDING MERGE)+==== Install packager dependencies ==== 
 + 
 +  ​* Install the **packager** dependencies using the Evergreen installer makefile:
  
 <code bash> <code bash>
Line 11: Line 13:
 </​code>​ </​code>​
  
-  ​* Create a local working branch for the release: ​+==== Update relator codes (requires commit bit) ==== 
 + 
 +  * During **beta** release building, update relator codes and commit the change to master (if necessary). ​ This happens before string freeze for translations,​ see https://​bugs.launchpad.net/​evergreen/​+bug/​1407507 for more details. 
 +  * As of the time of this writing, this automated process fails. ​ See https://​bugs.launchpad.net/​evergreen/​+bug/​1666987. 
 + 
 +<code bash> 
 +$ 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 
 +</​code>​ 
 + 
 + 
 +==== Prepare release notes (for major version bumps only) ==== 
 + 
 +=> See also the [[evergreen-docs:​release_notes_process|Release Notes Process for DIG Release Coordinator]] 
 + 
 +  * Create release notes 
 + 
 +<code bash> 
 +$ cd docs/​RELEASE_NOTES_NEXT 
 +$ ./​create_release_notes.sh -r 2_8 
 +</​code>​ 
 + 
 +  * Remove 2.8-specific files from docs/​RELEASE_NOTES_NEXT. 
 +    * Running the following in the docs/​RELEASE_NOTES_NEXT directory should work: 
 +<code bash> 
 +$ find . -mindepth 2 -name '​*.txt'​ -exec git rm {} \; 
 +$ find . -mindepth 2 -name '​*.adoc'​ -exec git rm {} \; 
 +</​code>​ 
 + 
 +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) ==== 
 + 
 +TODO: NEED TO INCLUDE PROCESS FOR DEALING WITH POEDITOR FOR THE ANGULAR STAFF INTERFACE 
 + 
 +  * 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 <code bash>$ cd build/i18n && make newpot</​code>​ 
 +    * Commit any changes that do more than modify metadata <code bash>​python3 build/​i18n/​scripts/​add_translations.py -c # use -h option for help</​code>​ 
 + 
 +==== 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"​
  
 <code bash>$ git checkout -b rel_2_8_0 origin/​master</​code>​ <code bash>$ git checkout -b rel_2_8_0 origin/​master</​code>​
  
-  ​Clone (or update) the translations repository in a new directory as a peer to Evergreen.+ 
 +==== Translations,​ Part 2: update_pofiles ==== 
 + 
 +  ​Next, clone (or update) the translations repository in a new directory as a peer to Evergreen:
  
 <code bash> <code bash>
Line 25: Line 73:
 </​code>​ </​code>​
  
-  * Sync translated files with Evergreen +  * NOTE: See here to find the correct translation branch for the version you are building: https://​code.launchpad.net/​evergreen/​+branches 
-    * Update PO files in Evergreen ​<code bash>+ 
 +  * Then, sync translated files with EvergreenUpdate PO files in the appropriate branch in origin: 
 + 
 +<code bash>
 $ Evergreen/​build/​i18n/​scripts/​update_pofiles -l translation-export -e Evergreen $ Evergreen/​build/​i18n/​scripts/​update_pofiles -l translation-export -e Evergreen
 $ cd Evergreen $ cd Evergreen
Line 32: Line 83:
 $ git commit -asm "​Translation updates - po files" $ git commit -asm "​Translation updates - po files"
 </​code>​ </​code>​
-    * Update pot in Evergreen <code bash> 
-$ cd build/i18n && make newpot 
-</​code>​ 
-    * Commit any changes that do more than modify metadata. ​ Using the script below, enter '​k'​ to keep and commit any non-trivial changes. <code bash> 
-$ cd ../../ # back to Evergreen 
-$ for file in $(git diff --name-only);​ do git diff $file; echo -e "​\n==================== ​ K for keep ==\n"; read X; if [ "​$X"​ = "​k"​ -o "​$X"​ = "​K"​ ]; then git add $file; fi; done 
-$ git checkout -- . # kill unneeded changes 
-$ git commit -asm "​Translation updates - newpot"​ 
-</​code>​ 
-    * **Or,** you could download and run [[https://​gist.github.com/​Dyrcona/​b9a56eab3c844a971910|this]]. 
  
-  ​* Edit ./​Open-ILS/​src/​perlmods/​lib/​OpenILS.pm and set:+==== Other version number changes ==== 
 + 
 +  ​* Edit ./​Open-ILS/​src/​perlmods/​lib/​OpenILS.pm and set (e.g., for 3.1.1):
 <code perl> <code perl>
-our $VERSION = '2.0800';+our $VERSION = '3.0101';
 </​code>​ </​code>​
 +
 +  * 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   * Commit the version change
Line 54: Line 99:
 </​code>​ </​code>​
  
-  * Update ​relator codes and commit the change (if necessary)+==== Update ​server upgrade documentation ====
  
-<code bash> +  * Replace references to base version (e.g. 2.12.1) with new version in docs/installation/server_upgrade.adoc (#.#.# and #_#_# versions)
-$ 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 +
-</​code>​+
  
-  * Create ​release ​notes (for major version bumps)+==== Run the release ​builder script ====
  
-<code bash> 
-$ cd docs/​RELEASE_NOTES_NEXT 
-$ ./​create_release_notes.sh -r 2_8 
-</​code>​ 
- 
-  * Remove 2.8-specific files from docs/​RELEASE_NOTES_NEXT. 
-    * Running the following in the docs/​RELEASE_NOTES_NEXT directory should work: 
-<code bash> 
-$ find . -mindepth 2 -name '​*.txt'​ -exec git rm {} \; 
-</​code>​ 
- 
-  * Replace references to current version with new version in docs/​installation/​server_upgrade.txt 
   * Run the release builder script   * Run the release builder script
 <code bash> <code bash>
 $ export PATH=$PATH:/​openils/​bin $ export PATH=$PATH:/​openils/​bin
-$ build/​tools/​make_release -c -v 2.8.0 -f origin/​tags/​rel_2_7_3+$ build/​tools/​make_release ​-x -c -v 2.8.0 -f origin/​tags/​rel_2_7_3
 </​code>​ </​code>​
  
Line 89: Line 118:
     * 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.      * 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 -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 ==== ==== Generate release docs ====
  
 <code bash> <code bash>
-# copy README and docs/RELEASE_NOTE_2_8.txt to ../​release/​ +# copy README and docs/RELEASE_NOTE_2_x.adoc to ../​release/​ 
-mv README README_2_8+cp README ​../release/README_2_8 
 +$ cp docs/​RELEASE_NOTES_2_8.adoc ../​release/​ 
 +$ cd ../release/
 # in ../release/ # in ../release/
 $ asciidoc -a toc -a numbered README_2_8 $ asciidoc -a toc -a numbered README_2_8
-$ asciidoc -a toc -a numbered RELEASE_NOTES_2_8.txt+$ asciidoc -a toc -a numbered RELEASE_NOTES_2_8.adoc
 # delete the originals # delete the originals
 +$ rm README_2_8
 +$ rm RELEASE_NOTES_2_8.adoc
 </​code>​ </​code>​
  
  
  
-==== Upload to web server ====+==== Upload to web server ​(requires lupin access) ​====
  
 Move the release files into the correct download directories:​ Move the release files into the correct download directories:​
Line 111: Line 146:
     * Release notes go in ''/​var/​www/​open-ils.org/​documentation/​release/''​     * Release notes go in ''/​var/​www/​open-ils.org/​documentation/​release/''​
  
-==== "​Tag"​ Working Branch ====+==== "​Tag"​ Working Branch ​(requires commit bit) ====
  
 <code bash> <code bash>
Line 117: Line 152:
 </​code>​ </​code>​
  
-==== Other notes ====+==== "​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!
  
-The following additional "​to-do'​s"​ that need to be moved into actual procedures: 
-    * As noted in https://​bugs.launchpad.net/​evergreen/​+bug/​1407507,​ run the relator_map script to generate the latest revised versions. 
dev/release_process/evergreen/2.8.1455891888.txt.gz · Last modified: 2016/02/19 09:24 by dyrcona

© 2008-2017 GPLS and others. Evergreen is open source software, freely licensed under GNU GPLv2 or later.
The Evergreen Project is a member of Software Freedom Conservancy.