(This is stolen and modified shamelessly from the Corona project's release-howto.txt file)
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.
The release candidate must be tested to compile using the following toolchains (note that this may be updated as different platforms/toolchains are supported):
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.
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.
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.
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.
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 :(
[PageInfo]
LastUpdate: 2023-05-27 11:47:53, ModifiedBy: alaskanemily
[Permissions]
view:all, edit:admins, delete/config:admins