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/04/18 17:20]
dbwells [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) ====+ 
 +==== 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.   * 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>​     * Update pot in Evergreen <code bash>$ cd build/i18n && make newpot</​code>​
-    * Commit any changes that do more than modify metadata+    * 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>​ 
-      * 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> +==== Setting up your git branch ​==== 
-$ cd ../../ # back to Evergreen + 
-$ for file in $(git diff --name-only);​ do git diff $file; echo -e "​\n====================  ​for keep ==\n"; read X; if [ "$X" = "​k"​ -o "​$X"​ = "​K"​ ]; then git add $file; fi; done +  * Create a local working branch ​for the release. ​ This will contain changes applicable to only this release, and become the release ​"tag" 
-$ git checkout -- . # kill unneeded changes + 
-$ git commit -asm "​Translation updates - newpot"​ +<code bash>$ git checkout -b rel_2_8_0 origin/​master</​code>​ 
-</​code>​ + 
-    + 
 +==== Translations,​ Part 2: update_pofiles ==== 
   * Next, clone (or update) the translations repository in a new directory as a peer to Evergreen:   * Next, clone (or update) the translations repository in a new directory as a peer to Evergreen:
  
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>​
  
Line 79: 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 105: 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 115: 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 133: 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 141: 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 147: 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.1524086402.txt.gz · Last modified: 2018/04/18 17:20 by dbwells

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