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.
then commit any changes:
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
When you want to bundle Java 11 JRE, you need to changeOpenJDK8U
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
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.
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.
- Go to OmegaT Builds
- 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;
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):
- [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:
When the confirmation email arrives, do:
Publish to SourceForge Files.
12. Set default downloads
Only if a Standard release:
- Go to SourceForge Files
- Navigate to the directory for this release
- For each platform: click the ⓘ button on the representative download for the platform
- Select the radio button for the platform under the Default Download For label
- Click Save
13. Publish the manual and Javadoc
14. Publish to Maven Central
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.
16. Verify all the user facing links
- Official site: omegat.org
- Documentation site: omegat-standard
- JavaDoc site: OmegaT API
- Sourceforge site: files section
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:
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.