Tags
Keine Tags

Frequently used words (click to add to your profile)

javac++androidlinuxc#windowsobjective-ccocoa誰得qtpythonphprubygameguibathyscaphec計画中(planning stage)翻訳omegatframeworktwitterdomtestvb.netdirectxゲームエンジンbtronarduinopreviewer

Recent Activity

2023-06-30
2023-06-27
2023-06-12

Side Bar

(This is stolen and modified shamelessly from the Corona project's release-howto.txt file)

Create Release Candidate Branch

When a new release is in process, a branch for the release candidate should be created with the format: rc_MAJOR_MINOR. For instance, the release candidate for 1.0 is named rc_1_0.

Test Compilation

The release candidate must be tested to compile using the following toolchains (note that this may be updated as different platforms/toolchains are supported):

  • OpenBSD amd64, gcc 8.5
  • Windows x86, MSVC 2015
  • Linux amd64, gcc 10.0.0 or higher

All of these toolchains should use the current release of Mercury. If you are pressed for time, Void Linux currently has a Mercury package to avoid compiling the toolchain on at least one of those platforms.

Ideally the release will also be tested with OpenBSD sparc64 and Linux armv6, as well as using clang 10.0.1 or higher, but these platforms may not be available to all developers and are not considered first-tier.

Run Demos

For all supported platforms, verify that the demos function correctly. See notes on which grades are expected to work for this step, as the low-level C grades do not function properly with OpenGL.

Fix Bugs

If any bugs that affect the demos or prevent building are found, changes to fix them should be pushed to the rc branch rather than to trunk. After the release is created, any changes will be merged back to trunk.

Create Release Branch

The last change on the rc branch should be pushed as the release branch, with the format release_MAJOR_MINOR. The current, cleaned source code should be added to a zip file, a tar.bz2 file, and a cpio.xz file, and set as new downloads.

Cleanup Trunk Branch

After a successful release is finished, the changes necessary (if any) should be merged back to the trunk branch. This is ideally done with cherry-picks to avoid a "rebase" commit. Also remember to push the trunk changes to the master branch on the remote, because OSDN doesn't let you change the default branch :(