Publish


Create a release branch in SVN

See "Tag related svn files".

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. For example, by running icuapps/trunk/webdemo/collation/build.sh (after modifying it for your system) and copy-pasting the output available-collators.txt into index.html. See for example the changes for http://bugs.icu-project.org/trac/ticket/11355

Tag related svn files

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

An enhancement release simply needs to have a list of what has been changed or added recently. A reference release should have much more detailed descriptions, especially of what API's have changed since the last reference release and migration steps.

Milestone on the main download page

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

<h3 style="background-color:rgb(102, 102, 102);color:white;margin-bottom:0pt;margin-top:12pt;padding-left:0.75em;font-size:1em;font-family:Arial,Helvetica,sans-serif">Development Milestones</h3>
<table border="0"><p style="font-size:10pt;font-family:Arial,Helvetica,sans-serif">Development milestone versions of ICU can be downloaded below. A development milestone is a stable snapshot build for next ICU major version.  These binaries and source code are provided for evaluation purpose and should be not be used in production environments.  New APIs or features in a milestone release might be changed or removed without notice.&nbsp;</p>
<tbody>
<tr>
<td style="width:105px;height:16px">&nbsp;<b>Release</b></td>
<td style="width:792px;height:16px">&nbsp;<b>Major Changes<br>
</b></td>
</tr>
<tr>
<td style="width:105px;height:29px">&nbsp;<a href="https://sites.google.com/site/icusite/download/471">4.8M1 (4.7.1)</a><br>
</td>
<td style="width:792px;height:29px">&nbsp;CLDR 1.9.1+, Parent locale override, Dictionary type trie, Alphabetic index (C), Compound text encoding (C), JDK7 Locale conversion (J)<br>
</td>
</tr>
</tbody>
</table>
</span><br>


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:   'ant release' from the top level checkout of ICU4J will create the 'release/' subdirectory containing all jars.   

C source:  [SRL: This section is currently broken. ] From a Unix platform:
Note that it is important that the C source contain pre-built data.

  1. Check out the ICU release with svn. These instructions will not package up local changes, because the pristine source will be re-exported from svn. 
  2. Configure and build ICU
  3. Run "make dist"
  4. icu4c-docs-*.zip, icu4c-src-*.zip, and icu4c-src-*.tgz will be created.
  5. Rename the files as appropriate and upload.
C binary:
  Currently, the IBM ICU Build System is the only source of C binary builds.  Unix builds are just the output of 'make install',  Windows builds are the rough equivalent.

MD5 files:
Create three different '.md5' files for icu4j (all files),  icu4c (source) and icu4c (binaries).
Use cfv: http://cfv.sf.net like this to create a .md5 file:
cfv -t md5 -C -f icu-……-src.md5 somefile.zip somefile.tgz
To verify, just run "cfv -f icu-……-src.md5" and it will verify that the md5 file contains hashes for all referenced files.

Check the ICU public site for the new release

Make sure that, aside from download pages, homepages, news items, feature lists and feature comparisons, etc. are updated. Upload the new API references. Update the User Guide.

Update the Trac release number list for ICU4C and ICU4J.

Update the ICU release number list by going to "Admin>Versions" in Trac, and add the new ICU version.

Post-release cleanup

  • Cleanup the milestone in the ICU Trac. Move left over items to future milestones. Close the milestone.
  • Look for TODO comments in the source code and file new tickets as required.
  • Delete and retag latest (ONLY after GA release, including maintenance!)
    • svn delete latest
    • svn cp <the latest tags/release-###  tag>  latest

Update online demos

Update online demos/tools to the latest version:

Online information update

Collation and comparison charts need to be updated. See charts/Performance & Size.

Old sensitive tickets

Unset the "sensitive" flag on old tickets. For example, on tickets that were fixed two or more releases ago.

Sample ticket query for ICU 59. Adjust the milestone selection as appropriate. Check the list in the ICU meeting.

Check duplicates and fixedbyotherticket! Keep the "sensitive" flag on tickets that were closed as duplicates of other tickets that are not yet fixed or have been fixed only very recently.

For removing the flag:

  • Select all query results.
  • Uncheck duplicates of unfixed or too-recent tickets.
  • At the bottom of the page, set the bulk update to do
    • field sensitive=no
    • field keywords=was_sensitive
    • update timestamps=yes
    • send emails=no
  • Submit & verify/spot-check.


Comments