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 revisionNext revisionBoth sides next revision | ||
dev:release_process:evergreen:how_to_build [2024/02/12 16:07] – draft of extract release notes from commits stompro | dev:release_process:evergreen:how_to_build [2024/05/16 10:52] – [Upload to web server (requires access to the evergreen-ils.org web server)] gmcharlton | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ===== Rolling an Evergreen Release ===== | + | ====== Rolling an Evergreen Release |
**¡This is a work in progress. | **¡This is a work in progress. | ||
+ | ==== Helpful videos ==== | ||
+ | |||
+ | These recordings show various release building activities. | ||
+ | |||
+ | * May 2023 [[https:// | ||
+ | * Nov 2023 [[https:// | ||
+ | * Dec 2023 [[https:// | ||
==== Prerequisites ==== | ==== Prerequisites ==== | ||
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. | ||
+ | |||
+ | See [[:: | ||
==== Install packager dependencies ==== | ==== Install packager dependencies ==== | ||
Line 14: | Line 23: | ||
<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 'trusty'; substitute the appropriate version keyword] | + | [Note that your Ubuntu version may be something other than 'focal'; substitute the appropriate version keyword] |
==== Update relator codes (requires commit bit) ==== | ==== Update relator codes (requires commit bit) ==== | ||
Line 33: | Line 42: | ||
==== Prepare release notes (for major version bumps only) ==== | ==== Prepare release notes (for major version bumps only) ==== | ||
- | => See also the [[evergreen-docs: | + | See also: [[evergreen-docs: |
- | * Cut a new release branch (such as rel_3_7): | + | Cut a new release branch (such as rel_3_13): |
- | < | + | |
- | git checkout -b rel_3_7 main | + | |
- | </ | + | |
- | * Update the version in the antora configuration | + | < |
- | <code bash> | + | Create release notes: |
- | $ vi docs/ | + | |
- | </ | + | |
- | edit ' | + | First, the RELEASE_NOTE_NEXT piece. |
- | * Create release notes | + | <code bash>$ cd docs/ |
+ | $ ./ | ||
- | <code bash> | + | After that script runs, you can remove 3.13-specific files from docs/ |
- | $ cd docs/ | + | |
- | $ ./create_release_notes.sh -r 2_8 | + | |
- | </ | + | |
- | * Remove 2.8-specific files from docs/ | ||
- | * Running the following in the docs/ | ||
<code bash> | <code bash> | ||
$ find . -mindepth 2 -name ' | $ find . -mindepth 2 -name ' | ||
$ find . -mindepth 2 -name ' | $ find . -mindepth 2 -name ' | ||
+ | $ echo "" | ||
</ | </ | ||
- | * < | + | Then, the extract release notes from the commit piece. |
- | * The script parses commits to pull the following: | + | |
- | * Release notes for bugs that use the Release-note: | + | Next, use the `extract_release_notes_from_commits.pl` script |
- | * Contributors | + | |
- | * Sponsors | + | |
- | * See [[https:// | + | * See [[https:// |
- | * Update these instructions. | + | |
<code bash> | <code bash> | ||
- | $ ../ | + | $ ../ |
+ | $ ../ | ||
</ | </ | ||
* Integrate the results into the release notes. | * Integrate the results into the release notes. | ||
- | + | * Make sure all directories in RELEASE_NOTES_NEXT are empty after the two scripts are run. If they are not, remove any lingering adoc files. | |
- | * Stage your changes and commit the release notes: | + | * Stage your changes and commit the release notes: |
+ | * < | ||
For an alpha or beta release, this rough process is probably enough. | For an alpha or beta release, this rough process is probably enough. | ||
+ | Once you are at the .0 release, update line 3 of the antora.yml configuration file in your release branch so it reads ' | ||
+ | |||
+ | <code bash>$ vi docs/ | ||
+ | |||
+ | Then, update the version in the site.yml file on main branch to include rel_3_13 on line 9. | ||
+ | |||
+ | <code bash>$ vi docs/ | ||
+ | |||
+ | ==== Translations, | ||
+ | |||
+ | This needs to be done once during the release cycle, typically at alpha or beta | ||
+ | |||
+ | Set up the new series branch using the instructions here: [[i18n: | ||
==== Translations, | ==== Translations, | ||
- | * 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_1/ | + | 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/ |
- | * Update pot in Evergreen <code bash>$ cd build/i18n && make newpot</ | + | |
- | * 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> | ||
==== Translations, | ==== Translations, | ||
- | * Export strings for the Angular staff client and import them into POEditor, following these [[: | ||
- | ==== Setting up your git branch ==== | + | Export strings for the Angular staff client and import them into POEditor, following the [[: |
- | * Create a local working | + | ==== Setting up your git branch |
+ | Create a local working branch for the release. | ||
<code bash>$ git checkout -b tags/ | <code bash>$ git checkout -b tags/ | ||
Line 105: | Line 121: | ||
# Clone the repository if necessary | # Clone the repository if necessary | ||
$ bzr branch lp: | $ bzr branch lp: | ||
- | $ bzr branch lp: | + | $ bzr branch lp: |
# If already cloned, simply pull in the latest changes | # If already cloned, simply pull in the latest changes | ||
$ cd translation-export-SERIES; | $ cd translation-export-SERIES; | ||
Line 134: | Line 150: | ||
==== Other version number changes ==== | ==== Other version number changes ==== | ||
- | * Edit ./ | + | * Edit ./ |
<code perl> | <code perl> | ||
- | our $VERSION = '3.0101'; | + | our $VERSION = '3.1300'; |
</ | </ | ||
- | * NOTE: The version string is two digits for each level after the decimal, so for example " | + | * NOTE: The version string is two digits for each level after the decimal, so for example " |
* Commit the version change | * Commit the version change | ||
<code bash> | <code bash> | ||
- | $ git commit -asm " | + | $ git commit -asm " |
</ | </ | ||
==== Update server upgrade documentation ==== | ==== Update server upgrade documentation ==== | ||
- | * Replace release version placeholders with the actual version numbers in docs/ | + | * Replace release version placeholders |
- | * If you are creating a beta or rc, add a hyphen and then beta or rc. For example, 3.12-rc. | + | * In vim, '': |
+ | * If you are creating a beta or rc, add a hyphen and then beta or rc. For example, 3.13-rc. | ||
* Replace the previous version placeholder (e.g. 3.X.W) with the last release number. | * Replace the previous version placeholder (e.g. 3.X.W) with the last release number. | ||
+ | * In vim, '': | ||
* Double check the correct minimum version of OpenSRF. | * Double check the correct minimum version of OpenSRF. | ||
* If the minimum version of OpenSRF has changed, also update the OpenSRF version number in docs/ | * If the minimum version of OpenSRF has changed, also update the OpenSRF version number in docs/ | ||
Line 157: | Line 175: | ||
==== Run the release builder script ==== | ==== Run the release builder script ==== | ||
- | * Run the release builder script | + | Run the release builder script: |
<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 (probably) the release candidate: <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 185: | Line 208: | ||
<code bash> | <code bash> | ||
- | # copy README and docs/ | + | # copy README and release notes to ../release/ |
- | $ cp README ../release/README_2_8 | + | $ export RELEASE=3_12 |
- | $ cp docs/RELEASE_NOTES_2_8.adoc ../release/ | + | $ cp README ../release/README_$RELEASE |
+ | $ cp docs/RELEASE_NOTES_$RELEASE.adoc ../release/ | ||
$ cd ../release/ | $ cd ../release/ | ||
# in ../release/ | # in ../release/ | ||
- | $ asciidoc -a toc -a numbered | + | $ asciidoc -a toc -a numbered |
- | $ asciidoc -a toc -a numbered | + | $ asciidoc -a toc -a numbered |
# delete the originals | # delete the originals | ||
- | $ rm README_2_8 | + | $ rm README_$RELEASE RELEASE_NOTES_$RELEASE.adoc |
- | $ rm RELEASE_NOTES_2_8.adoc | + | |
</ | </ | ||
- | ==== Upload to web server (requires | + | ==== Upload to web server (requires access |
- | Move the release files into the correct download directories: | + | Move the release files into the correct download directories |
* Previews / alphas / betas / release candidates go in ''/ | * Previews / alphas / betas / release candidates go in ''/ | ||
* Final releases and ChangeLog-* go in ''/ | * Final releases and ChangeLog-* go in ''/ | ||
Line 207: | Line 230: | ||
* 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., '' | ||
==== " | ==== " | ||
<code bash> | <code bash> | ||
- | git push origin tags/rel_3_12_1:tags/rel_3_12_1 | + | git push origin tags/rel_3_13_0:tags/rel_3_13_0 |
</ | </ | ||
dev/release_process/evergreen/how_to_build.txt · Last modified: 2024/07/18 09:17 by sandbergja