Contents

1. 1 Create a release branch in GitHub
2. 2 Upgrade LocaleExplorer and other demos/samples
3. 3 ICU Collation Demo
4. 4 Repository Branch and Tags
   1. 4.1 Creating Maintenance Branch.
      1. 4.1.1 Tagging
      2. 4.1.2 Maintenance release
   2. 4.2 ICU 58 and earlier
   3. 4.3 Create ICU download page
   4. 4.4 Maintenance release
5. 5 Milestone on the main download page
6. 6 Upload Release Source / Binaries
   1. 6.1 Java Source/Bin:
   2. 6.2 C source/binary:
      1. 6.2.1 Source and Linux Binaries:
      2. 6.2.2 Important: this step works with Unix make + docker.
      3. 6.2.3 Windows Binary:
   3. 6.3 Signing archives and creating checksums:
      1. 6.3.1 Step 1. PGP files:
      2. 6.3.2 Step 2. MD5 files:
      3. 6.3.3 Step 3. SHASUM512.txt
   4. 6.4 Update the Download Page Gadgets
7. 7 Check the ICU public site for the new release
8. 8 Update the Trac release number list for ICU4C and ICU4J.  <<?? STILL VALID ??>>
9. 9 Post-release cleanup
10. 10 Update online demos
11. 11 Online information update
12. 12 Old sensitive tickets
13. 13 Punt tickets
    1. 13.1 Update readme

Create a release branch in GitHub

Once the branch is created, only changes necessary for the target release are merged in from the trunk.

Upgrade LocaleExplorer and other demos/samples

... to the ICU project site.

Build the icuapps module following the README's. Update code and/or docs as needed. "Reference" platforms for icuapps are: RedHat Linux and win32. On Linux, icuapps is built against the "make install "'ed ICU. So, run ICU4C's configure with --prefix=/some/where pointing to where ICU4C should be installed, and also follow icuapps's README.

Install the new locale explorer and other demos/samples onto the public demo hosting site.

ICU Collation Demo

Update the ICU collation demo's index.html with the new ICU version’s available collators.

1. Do a clean build (configure, make clean, make install, make check).
1. Otherwise, the data build may not pick up a new locale into the coll/res_index.txt file.
2. Run icu-demos > webdemo/collation/build.sh (after modifying it for your system).
3. Copy-paste the output available-collators.txt into index.html.
1. Or, easier: Use a GUI difftool (e.g., meld) to compare the two and move the changes into index.html.
2. meld webdemo/collation/index.html ../available-collators.txt
4. See for example the changes for ICU-11355

For details see the comments at the start of the build.sh file.

Repository Branch and Tags

⚠ Careful! The following examples contain specific version, revision and ticket numbers. Adjust them for the current release! Easiest: Paste into an editor, fix, then paste into the terminal.

Creating Maintenance Branch.

Sanity check: Update to the latest repository revision. (Master branch if you copy from master, maintenance branch if you copy from there.)

Create the maintenance branch from the current known good master ref.

Tagging

https://github.com/unicode-org/icu/releases/new

Fill in the tag name, such as "release-63-rc" or "release-63-1", and make the target the "maint/maint-xx" branch (such as maint/maint-63).

Set the title to "ICU 63 RC" or "ICU 63.1".  Fill in the description using the text from the announcement email. (You can also look at previous releases and possibly re-use some of the generic text, such as links to the API docs, etc.)

We no longer need to add the note about Git LFS files, as GitHub now includes them in the auto-generated .zip downloads.

Click the "Publish Release" button to make the tag.

Note: The "latest" tag is no longer updated. It was agreed by the ICU-TC to be deleted around the 64.2 time-frame, as it doesn't work well with with Git. (You need to force-push the new tag, and if somebody has already cloned the repository, they might have something different for the "latest" tag).
A possible future alternative might be a sym-link folder, or HTTP redirect that points to the latest release.

Maintenance release

Create the maintenance release tag from the maintenance branch, as above.

Update the "latest" tag.

ICU 58 and earlier

Tag related svn files, for icu, icu4j and (for final releases) tools file trees. We tag the tools tree so that we can reproduce the Unicode tools that were used for the Unicode data files in this release.

For a Release Candidate, just tag, don't branch, and only tag icu & icu4j.

For the final release, branch then tag. Copy the trunk to maint/maint-4-8 and copy that to tags/release-4-8. Specify the source revision explicitly via -r so that you don't inadvertently pick up an unexpected changeset. Make sure that the trunk at the source revision is good.

We do not tag the data & icuapps trees. Steven Loomis writes on 2011-may-23:

My thought had been (in the CVS days) to take a 'snapshot' of these items. However, in SVN all you need is a date or a revision number (such as r30140).

So, probably, we don't need to tag these two (icuapps or data).

Tools are more important because those tools are actually used in the release.

Create ICU download page

Create the download page before the first milestone, if we have one, or before the release candidate.

Log into the ICU homepage Google Site. (If you don't have write access, ask one of the editors to grant you access.)

Verify that there is not already a page for the upcoming release: Either via the sitemap, or on the bottom of the main download page where it says something like "Subpages (27): View All".

Copy the download page for the last release: Go to that page, gear menu, Copy page; "Name your page" using just the major version number for now (e.g., "61") so that the page URL is just that number, select "Put page under Downloading ICU", click the red COPY button.

Adjust the new page as needed: Change the title to "Download ICU 61 Release Candidate" (with the right version number...), remove contents specific to the previous release, update all version numbers, update all links.

Put a big, bold+italics, red warning at the top like "This version has not been released yet. Use it for testing but not in production!"

Save the page. It is generally a good idea to save frequently. For further edits, simply go back into edit mode. (Keyboard shortcut 'e' for edit, ctrl+s for save.)

Add new contents for the upcoming release: Grab some text from the sibling Unicode and CLDR release notes, look at the proposal status doc for this release, make a pass through the api/enhancement tickets fixed in this release or under reviewing/reviewfeedback.

Look at the download pages of the last two releases for templates for things like a Migration Issues section etc.

Ask everyone on the team to add stuff & details.

Once the page has been created and various people are invited to edit it, everyone should keep editing short so that the page is not locked for others for long periods of time.

Maintenance release

For a maintenance release, look at the ICU 60 page which includes 60.2.

Milestone on the main download page

We had the following HTML on the main download page for ICU 4.8M1 = 4.7.1:

Upload Release Source / Binaries

Download Directories are located at, for example, 
  icu-project.org:/home/htdocs/ex/files/icu4c/4.4.2
corresponding to  http://download.icu-project.org/ex/files/icu4c/4.4.2/

Look at previous releases for an example.

Java Source/Bin:

Follow instructions here: Building ICU4J Release Files

C source/binary:

WORK IN PROGRESS

Source and Linux Binaries:

Important: this step works with Unix make + docker.

• Source and binaries are created in ./dist/.
• The names don't match what's needed on output so be sure to rename.

• This will produce a source tarball and will include a pre-compiled .dat file under icu4c/source/data/in/.
• Note: This tarball will also omit all of the data sub-directories containing locale data.
• Note that the source is taken from the git repository itself, and not your local checkout. (Thus it will exclude any local uncommitted changes).

Windows Binary:

• Manual process:
• Build with MSVC x64 Release. (See the ICU readme.html file for details).
• Open a command prompt.
• > cd C:\icu\icu4c\  (or wherever you have ICU located).
• > powershell
• > Set-ExecutionPolicy -Scope Process Unrestricted
• > .\packaging\distrelease.ps1 -arch x64
• This will produce the file "source\dist\icu-windows.zip", which will need to be renamed before uploading.
• For example, the binaries for ICU4C v61.1 generated with VS2017 were named "icu4c-61_1-Win64-MSVC2017.zip".
• Note: As of ICU 68, the pre-built binaries use MSVC2019 instead of MSVC2017.
• Using the output from the build bots:
• Navigate to the GitHub page for the commits on the "maint/maint-<version>" branch.
• Ex: https://github.com/unicode-org/icu/commits/maint/maint-64
• Click on the green check mark (✔) on the most recent/last commit. (It might be a red X if the builds failed, hopefully not).
• This will open up a pop-up with links to various CI builds.
• Click on one of the various links that says "Details" for the Azure CI builds.
• This will open up the GitHub overview of the build status.
• 
• Click on the link "View more details on Azure Pipelines" link.
• This will take you to the actual Azure CI build page.
• On the top right of the page there should be a button titled "Artifacts". Click this and it should show a drop-down with various ZIP files that you can download.
• 
• The ZIP may automatically download for you.
• However, if you are signed-in to visualstudio.com then you might see a dialog titled "Artifacts explorer".
• In this case click on the name, then the "..." button to download the zip file.
• 
• Download both the x64 (64-bit) and x86 (32-bit) ZIP files.
• For each architecture:
• Extract the Zip file. (It will have a name like "20190829.6_ICU4C_MSVC_x64_Release.zip").
• Navigate into the folder with the same name.
• Rename the file "icu-windows.zip" to the appropriate name:
• Ex: The x64 zip for version 64.1 was named "icu4c-64_1-Win64-MSVC2017.zip"
• Ex: The x86 zip for version 64.1 was named "icu4c-64_1-Win32-MSVC2017.zip"
• Note: Note: As of ICU 68, the pre-built binaries use MSVC2019 instead of MSVC2017.
• Note: For RC releases the name looked like this: "icu4c-64rc-Win64-MSVC2017.zip"
• AIX Bin: (AIX is broken and ignored for now.)
• login to gcc119.fsffrance.org and copy the ICU4C source archive created above to there.
• $ gzip -dc icu4c-XXX-src.tgz | tar xf -
• $ cd icu
• $ PATH=/opt/IBM/xlC/13.1.3/bin:$PATH source/runConfigureICU AIX
• (The above command line doesn't actually work, see ICU Ticket #13639 for a workaround.)
• $ gmake DESTDIR=/tmp/icu releaseDist
• That last step will create a directory in /tmp/icu - zip that up to make the release.
• In case /tmp happens to be full, see the mailing list archive for advice.

Signing archives and creating checksums:

Step 1. PGP files:

Sign all archives created above with your own personal PGP key. This creates a file with .asc as the suffix.

$ gpg --armor --detach-sign icu4c-xxx-xxx.zip

# To verify

$ gpg --verify icu4c-xxx-xxx.zip.asc

Step 2. MD5 files:

Use md5sum or cfv to create md5 hash sums for three groups of files:

icu4j (all files), 
icu4c (source),
icu4c (binaries).

Using md5sum to create and verify the checksum files:

md5sum source1 source2 ... sourceN > icu4c_sources.md5 
# To verify
md5sum -c icu4c_sources.md5 

Alternatively, use cfv to create and verify md5 files: