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 [2018/02/22 10:14]
csharp [Translations (i18n)]
dev:release_process:evergreen:2.8 [2020/09/17 12:31] (current)
gmcharlton add a todo re the Angular staff interface
Line 13: Line 13:
 </​code>​ </​code>​
  
-==== Setting up your git branch ==== +==== Update relator codes (requires commit bit) ====
- +
-  * Create a local working branch for the release:  +
- +
-<code bash>$ git checkout -b rel_2_8_0 origin/​master</​code>​ +
- +
-==== Update relator codes ====+
  
-  * During **beta** release building, update relator codes and commit the change (if necessary). ​ This happens before string freeze for translations,​ see https://​bugs.launchpad.net/​evergreen/​+bug/​1407507 for more details.+  * 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.   * As of the time of this writing, this automated process fails. ​ See https://​bugs.launchpad.net/​evergreen/​+bug/​1666987.
  
Line 30: Line 24:
 </​code>​ </​code>​
  
-==== Translations (i18n) ==== 
  
-  * During **beta** ​release, get the latest template changes and apply them to master ​(and any related branch if you make one).  It is important to merge any new pot changes to master so that Launchpad translations will get the latest strings that require translation. +==== Prepare ​release ​notes (for major version bumps only==== 
-    * Update pot in Evergreen <code bash>$ cd build/i18n && make newpot</​code>​ + 
-    * Commit any changes that do more than modify metadata: +=See also the [[evergreen-docs:release_notes_process|Release Notes Process for DIG Release Coordinator]] 
-      * Download and run [[https://​gist.github.com/​Dyrcona/​b9a56eab3c844a971910|Dyrcona'​s script]] like <code bash>​python3 add_translations.py -c # use -h option for help</​code>​ + 
-      Or manual process like follows: use script below, enter '​k'​ to keep and commit any non-trivial changes. ​<code bash> +  ​Create release notes 
-$ 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 +<code bash> 
-$ git checkout -- # kill unneeded changes +$ cd docs/RELEASE_NOTES_NEXT 
-$ git commit -asm "​Translation updates ​newpot"​+$ ./​create_release_notes.sh ​-r 2_8
 </​code>​ </​code>​
-    ​ + 
-  * Prior to final release, clone (or update) the translations repository in a new directory as a peer to Evergreen:+  * 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>​ 
 + 
 + 
 +==== 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 55: Line 75:
   * NOTE: See here to find the correct translation branch for the version you are building: https://​code.launchpad.net/​evergreen/​+branches   * NOTE: See here to find the correct translation branch for the version you are building: https://​code.launchpad.net/​evergreen/​+branches
  
-  * Then, sync translated files with Evergreen. Update PO files in Evergreen:+  * Then, sync translated files with Evergreen. Update PO files in the appropriate branch in origin:
  
 <code bash> <code bash>
Line 66: Line 86:
 ==== Other version number changes ==== ==== Other version number changes ====
  
-  * Edit ./​Open-ILS/​src/​perlmods/​lib/​OpenILS.pm and set:+  * 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 77: Line 99:
 </​code>​ </​code>​
  
-==== Prepare release notes (for major version bumps only) ==== 
- 
-  * 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. 
 ==== Update server upgrade documentation ==== ==== Update server upgrade documentation ====
  
Line 103: Line 108:
 <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 113: 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 ====
Line 131: Line 138:
  
  
-==== 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 139: 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 145: Line 152:
 </​code>​ </​code>​
  
-==== "​Forward-port"​ Version Upgrade Script ====+==== "​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! 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!
  
dev/release_process/evergreen/2.8.1519312483.txt.gz · Last modified: 2018/02/22 10:14 by csharp

© 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.