icu4c/source/data/misc/icuver.txt needs to be updated with the correct version number for ICU and its data.Note: We no longer use time bombs since ICU4J 52. In the trunk, logKnownIssue() is used for skipping known test failures. The new scheme no longer depends on the current ICU4J version, so there are no updates necessary in test codes when version number is updated. See Skipping Known Test Failures for more details.
Since ICU4J 4.6, you can quickly check the current version information by running jar main in icu4j.jar. For example,
$ java -jar icu4j.jar
prints out -
For updating ICU version numbers, follow the steps below.
2. icu4j/build.properties (For API change report and release target)
There is a static block starting at line 501 (as of 54.1) in the source file -
In the same file, starting at line 164 (as of 54.1) -
Only for the final release (including maintenance release), update the <version> item to the actual release version (e.g. "54.1", "4.8.1") Otherwise, use (next ver)-SNAPSHOT. (e.g. "55-SNAPSHOT").
5. Time Bombs (before ICU4J 52)
There might be some test cases intentionally skipped for the current ICU4J version. When ICU4J version is updated, these time bombed test cases may show up. In this case, you should:
Note: ICU4J time bomb - Before #7973, we used to use skipIfBeforeICU(int,int,int).
When a test case with time bomb still fails before a major release, the time bomb may be moved to the version before the first milestone of the next major release stream. For example, the time bomb (49,1) is not yet resolved before ICU4J 49 release, it should be updated to (50,0,1). This will prevent the error test case showing up during 49 maintenance releases, and appear before the first milestone of 50.0.1.
6. ICU4J Eclipse plug-in version (Eclipse release only)
ICU4J Eclipse plug-in use the standard Eclipse versioning scheme - X.Y.Z.v<build date>, for example, com.ibm.icu_4.2.1.v20100412.jar. By default, the build script compose the version string from icu4j.plugin.impl.version.string property in eclipse-build/build.properties with current date at the build time. However, when we tag a version, we want to freeze the build date part. To force a fixed version string, we add a property - icu4j.eclipse.build.version.string in the build.properties. For example, see tags/release-4-4-2-eclipse37-20110208/eclipse-build/build.properties.
This file is automatically generated when data is generated for ICU4J. The ICU4C version number string should be check to ensure that the correct version number is being used.
public static final String ICU4C_VERSION="50.0.2";
Note: The ICU4C version number string in this JAVA file is not really used for anything except for a few logln method calls. Perhaps this member is not really needed.
Make sure data file versions (for data contents) are properly assigned.
If any of the data files in the /icu/source/data/ directory has changed MANUALLY, upgrade the version number accordingly as well. If the contents of a resource bundle has changed, then increase the version number (at least the minor version field). The CLDR generated data should have the correct number.
Note from Markus (20090514, ICU 4.2 timeframe): Most data files automatically get their version numbers set by the LDML2ICUConverter, from CLDR version numbers. It is not clear what, if anything, needs to be done for this task.
Make sure data file format versions are updated. See http://userguide.icu-project.org/icudata#TOC-ICU-Data-File-Formats
If the format of a binary data file has changed, upgrade the format version in the UDataInfo header for that file. Better: Change the format version immediately when the format is changed. The change must be made in both the producer/generator and consumer/runtime code.
It is desirable to maintain backward compatibility, but sometimes impractical. Update the major version number for incompatible changes. Runtime code should permit higher minor version numbers for supported major versions.
We rarely use the third and fourth version number fields, except for UTrie (only version 1, not UTrie2) parameters that don't really change.
ICU Processes and Procedures > Throwing the Big Red Switch: How to ship ICU > Release & Milestone Tasks >