ICU Release Version Number Policy
ICU version number consists of up to four digits separated by dot.
- First two digits are used for major release number. Major release numbers for C and J are always synchronized.
- Even number at the second digit indicates an official release (e.g. 4.2)
- Odd number at the second digit indicates a development release (e.g. 4.3.1) for next major release.
- Third digit in an official release number indicates a maintenance update which is applicable to both C and J.
- Incremented only when C and J have common changes, such as CLDR update.
- For example, CLDR 1.7.1 changes are integrated into ICU4C 4.2.1 and ICU4J 4.2.1.
- Third digit in a development release number indicates a milestone
- ICU4C 4.3.1 -> ICU4C 4.4 development milestone 1
- Fourth digit in an official release number indicates a maintenance update only applicable to either C or J.
- For example, ICU4C 18.104.22.168 resolved some platform specific build issues and no equivalent changes in J.
Ticket Life Cycle
a description of the life cycle of an ICU Trac ticket, a feature
request or a bug report, from initial submittal through
implementation and review to release.
Feature Proposals and Design
- All API design proposals (for any additions and changes) must be proposed on the icu-design
- The proposal email itself must include: (See the template subpage)
- The proposed (new or changed) API signature(s)
- A Trac ticket number
- A Suggested API reviewer
- A deadline for
comments (usually one week from proposal).
- Background information in the proposal can
be helpful if the topic is complex. If there is a lot of information, write a design doc.
- The API signature must be reviewed by someone before submitting, and the reviewer must reply to the posting.
- In the ICU core team meeting, we have a regular agenda item to confirm recent API proposals (before or after code submission). Here we confirm that someone has reviewed it and no one objects.
- New/changed API that is discovered to not have proposal is withdrawn at or before the API Freeze milestone.
- We will try to write a tool to find API additions. The idea is to add a text file to the repository with expected additions/changes, and to check the actual set of APIs against that.
- There should not be major API additions after the API Slush milestone. Small additions (for example, new methods on existing classes) should be ok.
- Major functionality/new API or disruptive changes need to be implemented on a branch. The API there must be reviewed and confirmed before merging it to the trunk.
ICU Coding Style Guidelines
The ICU coding guidelines are
described in the user guide at
ICU Release Process
The release task list contains the list of
things to complete when releasing a a new version of the ICU libraries.
Design Documents for various ICU
services are maintained in the following locations: