同步操作将从 OpenHarmony/third_party_weston 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
To make a release of Weston, follow these steps.
Verify the test suites and codebase checks pass. All of the tests should either pass or skip.
ninja -C build/ test
Verify that the wayland and wayland-protocols version dependencies are correct, and that wayland-protocols has had a release with any needed protocol updates.
Update the first stanza of meson.build
to the intended version.
If the ABI has been broken, make sure libweston_major
has been bumped since
the last release.
Then commit your changes:
RELEASE_NUMBER="x.y.z"
RELEASE_NAME="[alpha|beta|RC1|RC2|official|point]"
git status
git commit meson.build -m "build: bump to version $RELEASE_NUMBER for the $RELEASE_NAME release"
git push
Run the release.sh
script to generate the tarballs, sign and upload them,
and generate a release announcement template. This script can be obtained
from X.org's modular package:
https://gitlab.freedesktop.org/xorg/util/modular/blob/master/release.sh
The script supports a --dry-run
option to test it without actually doing a
release. If the script fails on the distcheck step due to a test suite error
that can't be fixed for some reason, you can skip testsuite by specifying
the --dist
argument. Pass --help
to see other supported options.
release.sh .
Compose the release announcements. The script will generate *.x.y.z.announce files with a list of changes and tags. Prepend these with a human-readable listing of the most notable changes. For x.y.0 releases, indicate the schedule for the x.y+1.0 release.
PGP sign the release announcement and send it to wayland-devel@lists.freedesktop.org.
Update releases.html
in wayland.freedesktop.org with links to tarballs and
the release email URL. Copy tarballs produced by release.sh
to releases/
.
Once satisfied:
git commit -am "releases: add ${RELEASE_NUMBER} release"
git push
For x.y.0 releases, also create the release series x.y branch. The x.y branch is for bug fixes and conservative changes to the x.y.0 release, and is where we create x.y.z releases from. Creating the x.y branch opens up master for new development and lets new development move on. We've done this both after the x.y.0 release (to focus development on bug fixing for the x.y.1 release for a little longer) or before the x.y.0 release (like we did with the 1.5.0 release, to unblock master development early).
git branch x.y [sha]
git push origin x.y
The master branch's meson.build
version should always be (at least) x.y.90,
with x.y being the most recent stable branch. The stable branch's meson.build
version is just whatever was most recently released from that branch.
For stable branches, we commit fixes to master first, then git cherry-pick -x
them back to the stable branch.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。