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/13 14:46] – [Translations, Part 1: newpot (requires commit bit)] aneimandev:release_process:evergreen:how_to_build [2024/06/06 15:21] (current) – [Prerequisites] aneiman
Line 1: Line 1:
-===== Rolling an Evergreen Release =====+====== Rolling an Evergreen Release ======
  
 **¡This is a work in progress.  It will grow and change!** **¡This is a work in progress.  It will grow and change!**
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 60: Line 62:
 $ find . -mindepth 2 -name '*.txt' -exec git rm {} \; $ find . -mindepth 2 -name '*.txt' -exec git rm {} \;
 $ find . -mindepth 2 -name '*.adoc' -exec git rm {} \; $ find . -mindepth 2 -name '*.adoc' -exec git rm {} \;
 +$ echo "" > miscellaneous.adoc
 </code> </code>
  
Line 91: Line 94:
 ==== Translations, Part 0: New Series Branch ==== ==== Translations, Part 0: New Series Branch ====
  
-  * This needs to be done once during the release cycle, typically at alpha or beta +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:setting_up_a_new_series_translation|Setting Up a New Series Translation]]+ 
 +Set up the new series branch using the instructions here: [[i18n:setting_up_a_new_series_translation|Setting Up a New Series Translation]]
  
 ==== Translations, Part 1: newpot (requires commit bit) ==== ==== Translations, Part 1: newpot (requires commit bit) ====
Line 102: Line 106:
  
 ==== Translations, Part 1a: Angular Staff Client Updates (requires a POEditor account) ==== ==== Translations, Part 1a: Angular Staff Client Updates (requires a POEditor account) ====
-    * Export strings for the Angular staff client and import them into POEditor, following these [[:poeditor|instructions]].  You will need to be a poeditor.com admin to do this. 
  
-==== Setting up your git branch ====+Export strings for the Angular staff client and import them into POEditor, following the [[:poeditor|POEditor instructions]].  You will need to be a poeditor.com admin to do this.
  
-  * Create a local working branch for the release.  This will contain changes applicable to only this release, and become the release "tag": +==== 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 tags/rel_3_13_1 rel_3_13</code> <code bash>$ git checkout -b tags/rel_3_13_1 rel_3_13</code>
Line 148: Line 152:
 ==== Other version number changes ==== ==== Other version number changes ====
  
-  * Edit ./Open-ILS/src/perlmods/lib/OpenILS.pm and set (e.g., for 3.1.1):+  * Edit ./Open-ILS/src/perlmods/lib/OpenILS.pm and set (e.g., for 3.13.0):
 <code perl> <code perl>
-our $VERSION = '3.0101';+our $VERSION = '3.1300';
 </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" "3.12.0" would be "3.1200" If it is a beta or release candidate, do not include "beta" or "rc", just use the numeric version. +  * NOTE: The version string is two digits for each level after the decimal, so for example "3.0.5" would become "3.0005" "3.12.4" would be "3.1204" If it is a beta or release candidate, do not include "beta" or "rc", just use the numeric version. 
  
   * Commit the version change   * Commit the version change
  
 <code bash> <code bash>
-$ git commit -asm "bumping Perl version string for 2.8"+$ git commit -asm "bumping Perl version string for 3.13"
 </code> </code>
  
Line 164: Line 168:
  
   * Replace release version placeholders (X.X.X) with the actual version numbers in docs/modules/installation/pages/server_upgrade.adoc   * Replace release version placeholders (X.X.X) with the actual version numbers in docs/modules/installation/pages/server_upgrade.adoc
-  * * In vim, '':%s/3.X.X/3.12.3/'' will do the trick +    * In vim, '':%s/3.X.X/3.13.0/'' will do the trick 
-  * If you are creating a beta or rc, add a hyphen and then beta or rc.  For example, 3.12-rc.+  * 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, '':%s/3.X.W/3.12.2/'' will do the trick+    * In vim, '':%s/3.X.W/3.13.0/'' will do the trick
   * 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/modules/installation/pages/server_installation.adoc   * If the minimum version of OpenSRF has changed, also update the OpenSRF version number in docs/modules/installation/pages/server_installation.adoc
Line 173: Line 177:
 ==== 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:/openils/bin $ export PATH=$PATH:/openils/bin
-$ build/tools/make_release -v 2.8.0 -f origin/tags/rel_2_7_3+$ build/tools/make_release -v 3.13-beta -f origin/tags/rel_3_12_3
 </code> </code>
  
-  * 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 ~/Git/OpenSRF/src/javascript/ +    * 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> 
-    * 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.  +    * 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> 
-    * 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/tools/make_release -v 3.13.1 -f origin/tags/rel_3_13_0</code> 
-    * Enhanced Concerto Dataset upgrade *experimental +  * Use the -v flag when your branch name does not match the normal pattern, otherwise auto-detect works 
-      * 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 <postgres server hostname> +    * -j ~/Git/OpenSRF/src/javascript/ 
-      * -U <postgres username> # needs SUPERUSER and CREATEDB +  * 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.  
-      * -P <database password> +  * 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 <database port> +  * 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 <postgres server hostname> 
 +    * -U <postgres username> # needs SUPERUSER and CREATEDB 
 +    * -P <database password> 
 +    * -O <database port> 
 +    * 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.  These can be safely ignored. Note that you will get a lot of warnings related to the po translation files.  These can be safely ignored.
Line 223: Line 232:
     * 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) ====
  
 <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
 </code> </code>
  
dev/release_process/evergreen/how_to_build.1715625992.txt.gz · Last modified: 2024/05/13 14:46 by aneiman

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.