Skip to content

Release Procedure

0. Decide a release version

See Versioning for details about a versioning scheme.

1. Pre-announce on an omegat-dev mailing list

Especially if there is new translatable material, give the L10N team some lead time to update translations.

2. Decide bundled JREs versions

See if an update is available for the bundled JREs, and update ci/azure-pipelines/release_steps.yml if necessary.

3. Check manual versions

There is a version definition in doc_src/(lang)/version_(lang).properties files in each language folder. See it is as same as vernb variable in doc_src/(lang)/manualvariables.mod

Currently, it has not been unified and unchecked its parity. Please be caution of it.

3. Test

Ensure that ./gradlew check completes successfully.

4. Update manuals

Run the following.

./gradlew updateManuals

then commit any changes:

git add docs
git commit -sm 'docs(html): update html for preparation of Vx.x'

5. Update bundled JREs' major version

If you change a bundled JREs version, you also change build.gradle line 276-282 which is a file name match accordingly.

For example

    macJRE = fileTree(dir: assetDir, include: 'OpenJDK8U-jre_x64_mac_*.tar.gz')
When you want to bundle Java 11 JRE, you need to change OpenJDK8U to OpenJDK11U.

6. Update files with the release version

/src/org/omegat/Version.properties

It should have already had a major and minor version numbers that we expect for.

The Development version may have "_Beta" and you may need to update (remove) it according to the step-0 decision of a version number.

/release/changes.txt

You should update two parts.

  • Version header (including date!)
  • "[current] vs [previous]" line

and then commit the change.

git add src/org/omegat/Version.properties
git add release/changes.txt
git commit -sm 'Release version x.x'

7. Tag release revision

git tag vX.Y.Z

8. push commits and tags

When you are working on a release process of version 6.0 and later versions, the release pipeline will be automatically run on Azure DevOps when you push tag on GitHub.

git push origin vX.Y.Z

9. (optional) Run Release task on Azure Pipelines (version 5.8)

When you are working on a release process of version 5.8 series, you should run a release job manually.

  1. Go to OmegaT Builds
  2. Queue a Release Build, specifying for Branch the tag created earlier, e.g. refs/tags/vX.Y.Z.

After building, the dist-files will be deployed automatically to the SourceForge "Files" area.

This will publish all distfiles except for Signed Mac and WebStart.

10. Add signature to Windows distribution files locally, publish.

First, you should download published non-signed windows binaries from source forge.

Second, you should prepare your certification PEM file provided by CA company, such as Comodo, and Certum.

There are two ways to sign the executable depends on what OS you use. Please select A or B.

A. Signing code on linux

Insert your HSM: hardware security module USB dongle into PC. Prepare the shell script to sign executables that will be like as follows;

#!/bin/sh
infilie=$1
outfile=$2
toolexe=osslsigncode

engine=/usr/lib/x86_64-linux-gnu/engines-3/pkcs11.so
module=/opt/proCertumCardManager/sc30pkcs11-3.0.6.68-MS.so
# module=/usr/lib/x86_64-linux-gnu/engines-3/pkcs11.so

signer="Open Source Developer, Hiroshi Miura"
certs=cert/25044ce4fc92c7b98fcafdd60f46c724.pem

## execution
$toolexe sign -pkcs11engine $engine -pkcs11module $module -h sha256 -t http://time.certum.pl -certs $certs -askpass -n "${signer}" -in $infile -out $outfile

You will need to change a module line. You should download a driver SO file from CA provider and update to its path. You also need to change a certs line. You should update it with your PEM file path.

And then you should run like as follows;

sign.sh OmegaT_6.1.0_Beta_Windows_Without_JRE.exe OmegaT_6.1.0_Beta_Windows_Without_JRE_Signed.exe

There will be three files to be signed, _Without_JRE, _Windows and _Windows_64 flavours.

B. Signing code on Windows

First, you need to install Windows SDK from Windows Dev center. And all operations performed with Code Signing require a connected reader together with a card on which there is a Code Signing certificate.

To sign the file, use the following command on the command line (cmd.exe): 

signtool sign /n "[1]" /t [2] /fd [3] /v [4]

  • [1] Name or part of the name of the certificate's owner, which can be checked in the system tool certmg.msc
  • [2] Timestamp URL Address. When use Certum http://time.certum.pl For comodo http://timestamp.comodoca.com
  • [3] The name of the signature algorithm. Available sha1 and sha256,
  • [4] The path to the file to be signed.

A file is updated with signature. You should keep an original file for backup.

11. Build notarized Mac distfile locally, publish

First, make sure the local JRE is up-to-date.

Sign and submit binary to Apple:

./gradlew macNotarize

When the confirmation email arrives, do:

./gradlew macStapledNotarizedDistZip

Publish to SourceForge Files.

12. Set default downloads

Only if a Standard release:

  1. Go to SourceForge Files
  2. Navigate to the directory for this release
  3. For each platform: click the ⓘ button on the representative download for the platform
  4. Select the radio button for the platform under the Default Download For label
  5. Click Save

13. Publish the manual and Javadoc

./gradlew publishManual publishJavadoc

14. Publish to Maven Central

./gradlew publish

Then log onto Sonatype Nexus and publish the release.

15. Modify website

Some releases will impact the website structure. Make sure the website is up to date.

17. Announce to News, user group

18. Push a new version for version check

If no catastrophic problems are reported with the new version, once the website has been updated, bump the version check master file:

./gradlew publishVersion

Consider opening a ticket on the website to coordinate timing.

19. Cleanup

  • Bump version in Version.properties, changes.txt
  • Set fixed bug tickets and implemented RFEs to closed-fixed
  • Update ticket milestones if necessary

Note: Don't "clean up" old releases by moving them out of the way. It is important that distfile URLs remain stable.