dev:release_process:evergreen:how_to_build
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| dev:release_process:evergreen:how_to_build [2024/05/13 15:10] – [Run the release builder script] aneiman | dev:release_process:evergreen:how_to_build [2024/10/22 12:04] (current) – [Translations, Part 2: update_pofiles] update to a more modern evergreen version 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:// | ||
| See [[:: | See [[:: | ||
| Line 23: | Line 25: | ||
| <code bash> | <code bash> | ||
| # sudo make -f Open-ILS/ | # sudo make -f Open-ILS/ | ||
| - | $ sudo make -f Open-ILS/ | + | $ sudo make -f Open-ILS/ |
| </ | </ | ||
| - | [Note that your Ubuntu version may be something other than 'focal'; substitute | + | [Note that your Ubuntu version may be something other than 'jammy', or you may be using a different OS altogether. Substitute |
| ==== Update relator codes (requires commit bit) ==== | ==== Update relator codes (requires commit bit) ==== | ||
| Line 60: | Line 62: | ||
| $ find . -mindepth 2 -name ' | $ find . -mindepth 2 -name ' | ||
| $ find . -mindepth 2 -name ' | $ find . -mindepth 2 -name ' | ||
| + | $ echo "" | ||
| </ | </ | ||
| Line 99: | 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/ | 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/ | ||
| - | * Update pot in Evergreen <code bash>$ cd build/i18n && make newpot</ | + | * Update pot in the Evergreen |
| * From the Evergreen directory, run the python script to commit any changes that do more than modify metadata <code bash> | * From the Evergreen directory, run the python script to commit any changes that do more than modify metadata <code bash> | ||
| Line 126: | Line 129: | ||
| * NOTE: See here to find the correct translation branch for the version you are building: https:// | * NOTE: See here to find the correct translation branch for the version you are building: https:// | ||
| + | * 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." | ||
| * 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: | ||
| <code bash> | <code bash> | ||
| - | # series here is " | + | # series here is " |
| # that you are building | # that you are building | ||
| $ Evergreen/ | $ Evergreen/ | ||
| Line 145: | Line 149: | ||
| $ git add -A Open-ILS/ | $ git add -A Open-ILS/ | ||
| $ git commit -asm " | $ git commit -asm " | ||
| - | </ | ||
| - | |||
| - | ==== Other version number changes ==== | ||
| - | |||
| - | * Edit ./ | ||
| - | <code perl> | ||
| - | our $VERSION = ' | ||
| - | </ | ||
| - | |||
| - | * NOTE: The version string is two digits for each level after the decimal, so for example " | ||
| - | |||
| - | * Commit the version change | ||
| - | |||
| - | <code bash> | ||
| - | $ git commit -asm " | ||
| </ | </ | ||
| Line 177: | Line 166: | ||
| <code bash> | <code bash> | ||
| $ export PATH=$PATH:/ | $ export PATH=$PATH:/ | ||
| - | $ build/ | + | $ build/ |
| </ | </ | ||
| - | * Additional notes on make_release options: | + | Additional notes on make_release options: |
| - | * Use the -v flag when your branch name does not match the normal pattern, otherwise auto-detect works | + | * If you are building beta, use -beta for the first version value, for example: 3.13-beta. |
| - | * Use the -j flag to point at wherever your OpenSRF javascript lib source is, if not already installed | + | * Use the highest numbered previous version for the second version value. |
| - | * -j ~/ | + | |
| - | * The -f flag sets the branch " | + | * For a .0 release, the script should start from the highest point release in the previous series: <code bash>$ build/ |
| - | * 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. | + | * For a point release, the script should start from the previous point release in the series: <code bash>$ build/ |
| - | * Enhanced Concerto Dataset upgrade *experimental | + | |
| - | * This is optional, but if enough of the database tables have changed, it's a good idea. | + | * Use the -j flag to point at wherever your OpenSRF javascript lib source is, if not already installed |
| - | * -H < | + | * -j ~/ |
| - | * -U < | + | * The -f flag sets the branch " |
| - | * -P < | + | * 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. |
| - | * -O < | + | * Enhanced Concerto Dataset upgrade *experimental |
| - | * Omitting -H will cause make_release to skip the enhanced concerto upgrade steps. | + | * This is optional, but if enough of the database tables have changed, it's a good idea. |
| + | * -H < | ||
| + | * -U < | ||
| + | * -P < | ||
| + | * -O < | ||
| + | * Omitting -H will cause make_release to skip the enhanced concerto upgrade steps. | ||
| Note that you will get a lot of warnings related to the po translation files. | Note that you will get a lot of warnings related to the po translation files. | ||
| Line 224: | Line 218: | ||
| * Release notes go in ''/ | * Release notes go in ''/ | ||
| + | Because the release notes document is cumulative for each release series, a symbolic link exists for each release series so that (e.g.) '' | ||
| + | |||
| + | 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., '' | ||
| ==== " | ==== " | ||
| Line 234: | Line 231: | ||
| 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 doing a final release, you will need to copy the upgrade script you created to main and your current rel_x_y branch. | ||
| + | For example, if you just created a release 3.12.6 and were on the branch tags/ | ||
| + | |||
| + | <code bash> | ||
| + | git checkout rel_3_12 | ||
| + | git checkout tags/ | ||
| + | git commit -sm " | ||
| + | git checkout main | ||
| + | git cherry-pick rel_3_12 | ||
| + | </ | ||
| ==== 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:// | * Release team / outreach committee make announcements following [[https:// | ||
dev/release_process/evergreen/how_to_build.1715627427.txt.gz · Last modified: 2024/05/13 15:10 by aneiman