User Tools

Site Tools


dev:release_process:evergreen:how_to_build

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
dev:release_process:evergreen:how_to_build [2024/05/14 09:16] – [Prepare release notes (for major version bumps only)] also remove content from miscellaneous.adoc sandbergjadev:release_process:evergreen:how_to_build [2024/07/18 09:17] (current) – [Translations, Part 2: update_pofiles] sandbergja
Line 14: Line 14:
  
 Make sure you are in an environment with your git ssh keys, since you will need to be pushing commits to the git server. Make sure you are in an environment with your git ssh keys, since you will need to be pushing commits to the git server.
 +
 +To upload translations to Launchpad, you will also need to register an ssh key with Launchpad. See the [[https://code.launchpad.net/~evergreen-bugs/evergreen/translation-export-3.13|3.13 translation page for an example]].
  
 See [[::versioning|Versioning]] for notes on the numbering scheme. See [[::versioning|Versioning]] for notes on the numbering scheme.
Line 100: Line 102:
 During each release starting with beta, get the latest template changes and apply them to the main branch you are working from in origin (main/rel_3_13/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 (main/rel_3_13/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 the Evergreen directory as a non-root user <code bash>$ cd build/i18n && make newpot</code>
   * From the Evergreen directory, run the python script to 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>   * From the Evergreen directory, run the python script to 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>
  
Line 127: Line 129:
  
   * 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
 +  * It will give you an error "You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data."  You can safely ignore this, since you will just need to read public data for the next step -- no writing or private data needed.
  
   * Then, sync translated files with Evergreen. Update PO files in the appropriate branch in origin:   * Then, sync translated files with Evergreen. Update PO files in the appropriate branch in origin:
Line 185: Line 188:
   * Use the highest numbered previous version for the second version value.   * Use the highest numbered previous version for the second version value.
     * For example, building 3.13-beta, the script should start from the highest 3.12 release at the time of branching: <code bash>$ build/tools/make_release -v 3.13-beta -f origin/tags/rel_3_12_3</code>     * For example, building 3.13-beta, the script should start from the highest 3.12 release at the time of branching: <code bash>$ build/tools/make_release -v 3.13-beta -f origin/tags/rel_3_12_3</code>
-    * For a .0 release, the script should start from (probably) the release candidate: <code bash>$ build/tools/make_release -v 3.13.0 -f origin/tags/rel_3_13_rc</code>+    * For a .0 release, the script should start from the highest point release in the previous series: <code bash>$ build/tools/make_release -v 3.13.0 -f origin/tags/rel_3_12_3</code>
     * For a point release, the script should start from the previous point release in the series: <code bash>$ build/tools/make_release -v 3.13.1 -f origin/tags/rel_3_13_0</code>     * For a point release, the script should start from the previous point release in the series: <code bash>$ build/tools/make_release -v 3.13.1 -f origin/tags/rel_3_13_0</code>
   * Use the -v flag when your branch name does not match the normal pattern, otherwise auto-detect works   * Use the -v flag when your branch name does not match the normal pattern, otherwise auto-detect works
Line 230: Line 233:
     * Release notes go in ''/var/www/open-ils.org/documentation/release/''     * Release notes go in ''/var/www/open-ils.org/documentation/release/''
  
 +Because the release notes document is cumulative for each release series, a symbolic link exists for each release series so that (e.g.) ''RELEASE_NOTES_3_666.html'' points to the latest release in the series (e.g., ''RELEASE_NOTES_3_666.html'' → ''RELEASE_NOTES_3_666_7.html''). Therefore, when uploading the release notes, update that symbolic link. When uploading the first alpha or beta for a series, it will be necessary to create the symbolic link.
 +
 +When updating the downloads page to the website, the URL should use the symbolic link, not the release notes for the specific release, e.g., ''https://evergreen-ils.org/documentation/release/RELEASE_NOTES_3_666.html'', not ''https://evergreen-ils.org/documentation/release/RELEASE_NOTES_3_666_7.html''.
 ==== "Tag" Working Branch (requires commit bit) ==== ==== "Tag" Working Branch (requires commit bit) ====
  
Line 240: Line 246:
 If doing a final release, you will need to copy the upgrade script you created to main 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 main 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!
  
 +For example, if you just created a release 3.12.6 and were on the branch tags/rel_3_12_6:
 +
 +<code bash>
 +git checkout rel_3_12
 +git checkout tags/rel_3_12_6 -- Open-ILS/src/sql/Pg/version-upgrade/3.12.5-3.12.6-upgrade-db.sql
 +git commit -sm "Forward-port 3.12.5-3.12.6 upgrade script"
 +git checkout main
 +git cherry-pick rel_3_12
 +</code>
 ==== Announcing and recording the release ==== ==== Announcing and recording the release ====
     * Update evergreen_history.txt file in history repo with release dates.     * Update evergreen_history.txt file in history repo with release dates.
     * Release team / outreach committee make announcements following [[https://docs.google.com/document/d/1FpCvnAgL0TiHL3L-lNWbEd7FLBzVs6UV0L1kIoN70Jw/edit?usp=sharing|publicity checklist]]     * Release team / outreach committee make announcements following [[https://docs.google.com/document/d/1FpCvnAgL0TiHL3L-lNWbEd7FLBzVs6UV0L1kIoN70Jw/edit?usp=sharing|publicity checklist]]
  
dev/release_process/evergreen/how_to_build.1715692609.txt.gz · Last modified: 2024/05/14 09:16 by sandbergja

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.