Multilingual Release Schedule

Standard Process


[[{INSERTTablePlugin} | {INSERT TablePlugin}]]


Start End Base Schedule ML Milestones QA
Feature Freeze L10n scope determined.
* L10nkits are generated regularly but do not need to be 100% accurate.
* ML build can be downloaded regularly.
* Integrate l10n files into the source tree to get build (latest base sources + previous l10n resources)
* Fix open l10n bugs
* Monitor P1 bugs
* Create L10n plan and schedule
* Start l10nkit tracking for volume analysis, NOI18N, unnecessary files, missing files
NOTE: Janice to give feedback early on to Ken and pteam/relteam so kits can be 100% accurate at Code Freeze.
Phase 1: Sanity testing cycle; verify reported issues, learn new features, create test cases.
Beta Go/No Go * Determine translation schedule (number of cycles, scope)
* 1st UI/msg handoff to translators
Phase 1: Sanity testing cycle to coincide with translation commits (every 2 weeks?); verify reported issues, learn new features, create test cases. Test cases ready before integration of 1st translations.
UI/msg freeze * L10n test plan and test cases finalized
* 2nd UI/msg handoff to translators
Phase 2: test the latest integrated l10n
UI freeze + 7d * I18N product l10n kit list/kit internal completion
* Installer i18n complete
* HR/Code freeze
* ML Daily builds start
* Check the final updates for UI/msg and start the final translation cycle. 1st and only handoff for Help to translators.
L10n internal kit+5d * I18N product l10n kit complete and accurate and released to translation team
Repeat cycle:
* Translation
* Review
* Integration
Testing & bug fixing
HR+2w RC1 Testing & bug fixing
RCn Testing & bug fixing
HR+4w English FCS Testing & bug fixing
* 1st and only handoff of Webdocs to translators
ML FCS Go/No Go minus 1 week ML freeze: Final l10n integration) Phase 3: FCS QA
ML FCS build ^
ML FCS testing ^
ML FCS Go/No Go ^
FCS+3 days ML Go Live
UC l10nkit
Patch 1 l10nkit
Patch n l10nkit


  • Request Build Engineering
  • Start ML build before Beta and make it publicly available (as was dev build)
  • Generate the l10nkit regularly before Beta (though it does not need to be 100% accurate until Code Freeze)



  • NetBeans releases every six (6) months (September/March)
  • NetBeans ML FCS is 30 days after the English FCS (unless major holiday breaks)
  • NetBeans ML consists of
  • Software (UI/messages, Help)
  • Documentation (release notes, install guide, tutorials, product pages, etc.)
  • Update Center translations
  • Patch(es) translations
  • Other Bundles, such as NB/JDK, NB/MySQL, etc.
  • It should be possible to localize the software within six weeks (start to finish)
  • The Sun localization team will use the WorldServer tool for workflow to and from translation companies, for scoping and leveraging files, for pre and post processing of Translation Memory. Community localization teams may decide to use a variety of tools to edit translations and preserve translation memory.
  • Most file types require pre-translation and post-translation processing tasks link to them here
  • Number of handoffs of files to localization:
  • messages: 2-3 (English Beta, English code freeze, English RC)
  • Help: 1 (English code freeze)
  • Webdocs: 1 (English RC or FCS). Set following priorities for translation
  • Priority 1: Release documents ( index pages, release notes, install guide)
  • Priority 2: Product pages
  • Priority 3: Tutorials and learning paths
  • Priority 4: Other
  • Translations for each content type (messages, Help, docs) should be received as they are completed. It should not be necessary to wait for all files of one type (message properties for example) to be translated at once and delivered when all are complete. This allows for staggered deliveries and review and testing tasks to be on-going.
  • Must be able to start Help translations BEFORE all of UI/msgs are translated and archived in the TM. Must be able to start the Webdocs translations before the Help is translated and archived in TM.
  • ML daily builds needed on from DATE or MILESTONE to test committed translations. For Sun and community.
  • Official ML builds needed: FCS or also Beta and RC?

Release Milestone Definitions

Milestone Definition
Feature Freeze new features are substantially complete. Bug fixes are expected after feature freeze. Bug fixes may include API changes or minor feature changes based on review and feedback; however, these kinds of changes must remain limited in order for the component to be considered substantially complete. Docs, SQE, Localization and others count on the feature set to be stable following feature freeze.
Stabilization Phase The period of time between feature freeze and code freeze. The purpose of the stabilization phase is to find and fix bugs and generally finish up the product. As a rule, new functionality is not introduced during the Stabilization Phase; however, the release team may allow exceptions given a sufficiently convincing business case.
High Resistance Mode all planned code changes are complete. Further bug fixing is likely during high resistant mode as a result of continued SQE testing or external feedback. This fixing should be limited to high priority bugs that are approved by the release team. Note that in small releases, high resistant mode and feature freeze can be coincident. In larger releases its typical for high resistant mode to follow feature freeze by several months.
Code Freeze no code integration is allowed. Minor changes in the documentation, branding images, L10n strings, and other changes that are necessary for the release and don't change the functionality can be done.
Release Candidate The putative final build of a release. All planned changes for the release must be made before a release candidate can be declared. Put another way, a release candidate may not be declared if the release team knows of any showstopper issues. A release candidate is produced during the high resistant mode. Release candidates are often provisionally released for a period of time during which they are also subject to continued testing. If any showstopper bugs are found during this period, the bug is fixed, a new release candidate is built and the process repeats. If no showstoppers are found during the RC period, the release candidate is promoted to GA status.
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo