The build scripts run on GNU/Linux and macOS. The Windows binaries are generated on Intel GNU/Linux, using mingw-w64.
For GNU/Linux, the prerequisites are:
curl
(installed via the system package manager)git
(installed via the system package manager)docker
(preferably a recent one, installed from docker.com)npm
(shipped with Node.js; installed via nvm, not the system package manager)xpm
(installed vianpm
)
For macOS, the prerequisites are:
npm
(shipped with Node.js; installed via nvm)xpm
(installed vianpm
)- the Command Line Tools from Apple
For details on installing them, please read the XBB prerequisites page.
If you already have a functional configuration from a previous run, it is recommended to update xpm:
npm install --location=global xpm@latest
The project is hosted on GitHub:
To clone the stable branch (xpack
), run the following commands in a
terminal (on Windows use the Git Bash console):
rm -rf ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
git clone https://github.com/xpack-dev-tools/mingw-w64-gcc-xpack.git \
~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git
For development purposes, clone the xpack-develop
branch:
rm -rf ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
mkdir -p ~/Work/xpack-dev-tools && \
git clone \
--branch xpack-develop \
https://github.com/xpack-dev-tools/mingw-w64-gcc-xpack.git \
~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git
Or, if the repo was already cloned:
git -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git pull
The project has a dependency to a common helper; clone the
xpack-develop
branch and link it to the central xPacks store:
rm -rf ~/Work/xpack-dev-tools/xbb-helper-xpack.git && \
mkdir -p ~/Work/xpack-dev-tools && \
git clone \
--branch xpack-develop \
https://github.com/xpack-dev-tools/xbb-helper-xpack.git \
~/Work/xpack-dev-tools/xbb-helper-xpack.git && \
xpm link -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git
Or, if the repo was already cloned:
git -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git pull
xpm link -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git
The xPack MinGW-w64 GCC release schedule generally follows the original GNU releases. Initial X.[01].0 releases are skipped, and the first is X.2.0, around September. At the same time updates for the previous 3 versions (like (X-1).3.0, (X-2).4.0, (X-3).5.0) are released.
Before starting the build, perform some checks and tweaks.
The build scripts are available in the scripts
folder of the
xpack-dev-tools/mingw-w64-gcc-xpack
Git repo.
To download them on a new machine, clone the xpack-develop
branch,
as seen above.
In the xpack-dev-tools/mingw-w64-gcc-xpack
Git repo:
- switch to the
xpack-develop
branch - pull new changes
- if needed, merge the
xpack
branch
No need to add a tag here, it'll be added when the release is created.
Check the latest versions at https://github.com/xpack-dev-tools/ and
update the dependencies in package.json
.
- identify the latest release from https://gcc.gnu.org/releases.html
- download the tar.xz archive from https://mirrors.nav.ro/gnu/gcc/
- check
gcc/BASE-VER
Determine the version (like 13.2.0
) and update the scripts/VERSION
file; the format is 13.2.0-1
. The fourth number is the xPack release number
of this version. A fifth number will be added when publishing
the package on the npm
server.
Check GitHub issues and pull requests:
and fix them; assign them to a milestone (like 13.2.0-1
).
Normally README.md
should not need changes, but better check.
Information related to the new version should not be included here,
but in the version specific release page.
- update version in
README-MAINTAINER.md
- update version in
README.md
Use a new version, suffixed by .pre
.
- open the
CHANGELOG.md
file - check if all previous fixed issues are in
- add a new entry like * v13.2.0-1 prepared
- commit with a message like prepare v13.2.0-1
- open the
scripts/versioning.sh
file - add a new
if
with the new version before the existing code
To keep the development repository fork in sync with the upstream GCC
repository, in the xpack-dev-tools/gcc
Git repo:
- checkout
master
- merge from
upstream/master
- checkout
xpack-develop
- merge
master
- fix conflicts
- checkout
xpack
- merge
xpack-develop
Possibly add a tag here.
Note: the current versions do not use the fork repo.
The builds currently run on 5 dedicated machines (Intel GNU/Linux, Arm 32 GNU/Linux, Arm 64 GNU/Linux, Intel macOS and Apple Silicon macOS).
Before the real build, run test builds on all platforms.
All actions are defined as xPack actions and can be conveniently triggered via the VS Code graphical interface, using the xPack extension.
For Intel macOS, first run the build on the development machine
(wksi
, a recent macOS):
Update the build scripts (or clone them at the first use):
# Update the build scripts.
git -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git pull
xpm run install -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git
git -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git pull
xpm link -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git
xpm run link-deps -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git
xpm run deep-clean --config darwin-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm install --config darwin-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm run build-develop --config darwin-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git
For a debug build:
xpm run build-develop-debug --config darwin-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git
The build takes about 51 minutes.
When functional, push the xpack-develop
branch to GitHub.
Run the native build on the production machine
(xbbmi
, an older macOS);
start a VS Code remote session, or connect with a terminal:
caffeinate ssh xbbmi
Repeat the same steps as before.
git -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git pull && \
xpm run install -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
git -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git pull && \
xpm link -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git && \
xpm run link-deps -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
\
xpm run deep-clean --config darwin-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm install --config darwin-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm run build-develop --config darwin-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git
About 48 minutes later, the output of the build script is a compressed
archive and its SHA signature, created in the deploy
folder:
$ ls -l ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/build/darwin-x64/deploy
total 493224
-rw-r--r-- 1 ilg staff 245329754 Sep 1 12:22 xpack-mingw-w64-gcc-13.2.0-1-darwin-x64.tar.gz
-rw-r--r-- 1 ilg staff 113 Sep 1 12:22 xpack-mingw-w64-gcc-13.2.0-1-darwin-x64.tar.gz.sha
Run the native build on the production machine
(xbbma
, an older macOS);
start a VS Code remote session, or connect with a terminal:
caffeinate ssh xbbma
Update the build scripts (or clone them at the first use) and run the following:
git -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git pull && \
xpm run install -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
git -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git pull && \
xpm link -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git && \
xpm run link-deps -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
\
xpm run deep-clean --config darwin-arm64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm install --config darwin-arm64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm run build-develop --config darwin-arm64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git
About 25 minutes later, the output of the build script is a compressed
archive and its SHA signature, created in the deploy
folder:
$ ls -l ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/build/darwin-arm64/deploy
total 459656
-rw-r--r-- 1 ilg staff 235223655 Sep 1 12:03 xpack-mingw-w64-gcc-13.2.0-1-darwin-arm64.tar.gz
-rw-r--r-- 1 ilg staff 115 Sep 1 12:03 xpack-mingw-w64-gcc-13.2.0-1-darwin-arm64.tar.gz.sha
Run the docker build on the production machine (xbbli
);
start a VS Code remote session, or connect with a terminal:
caffeinate ssh xbbli
Update the build scripts (or clone them at the first use) and run the following:
git -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git pull && \
xpm run install -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
git -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git pull && \
xpm link -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git && \
xpm run link-deps -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
\
xpm run deep-clean --config linux-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm run docker-prepare --config linux-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm run docker-link-deps --config linux-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm run docker-build-develop --config linux-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git
About 33 minutes later, the output of the build script is a compressed
archive and its SHA signature, created in the deploy
folder:
$ ls -l ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/build/linux-x64/deploy
total 273280
-rw-r--r-- 1 ilg ilg 279829973 Sep 1 09:08 xpack-mingw-w64-gcc-13.2.0-1-linux-x64.tar.gz
-rw-r--r-- 1 ilg ilg 112 Sep 1 09:08 xpack-mingw-w64-gcc-13.2.0-1-linux-x64.tar.gz.sha
Clean the build folder and prepare the docker container:
git -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git pull && \
xpm run install -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
git -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git pull && \
xpm link -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git && \
xpm run link-deps -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
\
xpm run deep-clean --config win32-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm run docker-prepare --config win32-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm run docker-link-deps --config win32-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm run docker-build-develop --config win32-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git
About 59 minutes later, the output of the build script is a compressed
archive and its SHA signature, created in the deploy
folder:
$ ls -l ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/build/win32-x64/deploy
total 313576
-rw-r--r-- 1 ilg ilg 321092904 Sep 1 09:28 xpack-mingw-w64-gcc-13.2.0-1-win32-x64.zip
-rw-r--r-- 1 ilg ilg 109 Sep 1 09:28 xpack-mingw-w64-gcc-13.2.0-1-win32-x64.zip.sha
Run the docker build on the production machine (xbbla
);
start a VS Code remote session, or connect with a terminal:
caffeinate ssh xbbla
Update the build scripts (or clone them at the first use) and run the following:
git -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git pull && \
xpm run install -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
git -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git pull && \
xpm link -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git && \
xpm run link-deps -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
\
xpm run deep-clean --config linux-arm64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm run docker-prepare --config linux-arm64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm run docker-link-deps --config linux-arm64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm run docker-build-develop --config linux-arm64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git
About 3h14 later, the output of the build script is a compressed
archive and its SHA signature, created in the deploy
folder:
$ ls -l ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/build/linux-arm64/deploy
total 265852
-rw-r--r-- 1 ilg ilg 272222617 Sep 1 11:42 xpack-mingw-w64-gcc-13.2.0-1-linux-arm64.tar.gz
-rw-r--r-- 1 ilg ilg 114 Sep 1 11:42 xpack-mingw-w64-gcc-13.2.0-1-linux-arm64.tar.gz.sha
Run the docker build on the production machine (xbbla32
);
start a VS Code remote session, or connect with a terminal:
caffeinate ssh xbbla32
Update the build scripts (or clone them at the first use) and run the following:
git -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git pull && \
xpm run install -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
git -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git pull && \
xpm link -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git && \
xpm run link-deps -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
\
xpm run deep-clean --config linux-arm -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm run docker-prepare --config linux-arm -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm run docker-link-deps --config linux-arm -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
xpm run docker-build-develop --config linux-arm -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git
About 2h47 later, the output of the build script is a compressed
archive and its SHA signature, created in the deploy
folder:
$ ls -l ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/build/linux-arm/deploy
total 247888
-rw-r--r-- 1 ilg ilg 253827378 Sep 1 11:15 xpack-mingw-w64-gcc-13.2.0-1-linux-arm.tar.gz
-rw-r--r-- 1 ilg ilg 112 Sep 1 11:15 xpack-mingw-w64-gcc-13.2.0-1-linux-arm.tar.gz.sha
- check and possibly update the
ls -l
output in README-MAINTAINER
Copy/paste the full list of links displayed at the end of the build, in sequence, for each platform (GNU/Linux, macOS, Windows), and check the differences compared to the repository.
Commit if necessary.
In some cases it is necessary to run a debug session in the binaries, or even in the libraries functions.
For these cases, the build script accepts the --debug
options.
There are also xPack actions that use this option (build-develop-debug
and docker-build-develop-debug
).
The XBB build scripts use a local cache such that files are downloaded only during the first run, later runs being able to use the cached files.
However, occasionally some servers may not be available, and the builds may fail.
The workaround is to manually download the files from an alternate
location (like
https://github.com/xpack-dev-tools/files-cache/tree/master/libs),
place them in the XBB cache (Work/cache
) and restart the build.
The automation is provided by GitHub Actions and three self-hosted runners.
Run the generate-workflows
to re-generate the
GitHub workflow files; commit and push if necessary.
- on the development machine (
wksi
) open ssh sessions to the build machines (xbbmi
,xbbma
,xbbli
,xbbla
andxbbla32
):
caffeinate ssh xbbmi
caffeinate ssh xbbma
caffeinate ssh xbbli
caffeinate ssh xbbla
caffeinate ssh xbbla32
For xbbli
& xbbla
start two runners:
screen -S ga
~/actions-runners/xpack-dev-tools/1/run.sh &
~/actions-runners/xpack-dev-tools/2/run.sh &
# Ctrl-a Ctrl-d
On all other machines start a single runner:
screen -S ga
~/actions-runners/xpack-dev-tools/run.sh &
# Ctrl-a Ctrl-d
- push the
xpack-develop
branch to GitHub - possibly push the helper project too
From here it'll be cloned on the production machines.
Publish a new release of the helper and update the reference in package.json
.
Check if the build machines have enough free space and eventually
do some cleanups (df -BG -H /
on Linux, df -gH /
on macOS).
To remove previous builds, use:
rm -rf ~/Work/xpack-dev-tools/*/build
To trigger the GitHub Actions build, use the xPack action:
trigger-workflow-build-xbbmi
trigger-workflow-build-xbbma
trigger-workflow-build-xbbli
trigger-workflow-build-xbbla
trigger-workflow-build-xbbla32
This is equivalent to:
bash ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/xpacks/@xpack-dev-tools/xbb-helper/github-actions/trigger-workflow-build.sh --machine xbbmi
bash ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/xpacks/@xpack-dev-tools/xbb-helper/github-actions/trigger-workflow-build.sh --machine xbbma
bash ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/xpacks/@xpack-dev-tools/xbb-helper/github-actions/trigger-workflow-build.sh --machine xbbli
bash ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/xpacks/@xpack-dev-tools/xbb-helper/github-actions/trigger-workflow-build.sh --machine xbbla
bash ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/xpacks/@xpack-dev-tools/xbb-helper/github-actions/trigger-workflow-build.sh --machine xbbla32
These scripts require the GITHUB_API_DISPATCH_TOKEN
variable to be present
in the environment, and the organization PUBLISH_TOKEN
to be visible in the
Settings → Action →
Secrets
page.
These commands use the xpack-develop
branch of this repo.
The builds take about 3 hours to complete:
xbbmi
: 0h52 (nuc)xbbma
: 0h26xbbli
: 0h34 Linux, 1h00 Windowsxbbla
: 3h15xbbla32
: 2h48
The workflow result and logs are available from the Actions page.
The resulting binaries are available for testing from pre-releases/test.
The automation is provided by GitHub Actions.
To trigger the GitHub Actions tests, use the xPack actions:
trigger-workflow-test-prime
trigger-workflow-test-docker-linux-intel
trigger-workflow-test-docker-linux-arm
These are equivalent to:
bash ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/xpacks/@xpack-dev-tools/xbb-helper/github-actions/trigger-workflow-test-prime.sh
bash ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/xpacks/@xpack-dev-tools/xbb-helper/github-actions/trigger-workflow-test-docker-linux-intel.sh
bash ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/xpacks/@xpack-dev-tools/xbb-helper/github-actions/trigger-workflow-test-docker-linux-arm.sh
These scripts require the GITHUB_API_DISPATCH_TOKEN
variable to be present
in the environment.
These actions use the xpack-develop
branch of this repo and the
pre-releases/test
binaries.
The tests results are available from the Actions page.
Since GitHub Actions provides a single version of macOS, the multi-version macOS tests run on Travis.
To trigger the Travis test, use the xPack action:
trigger-travis-macos
This is equivalent to:
bash ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/xpacks/@xpack-dev-tools/xbb-helper/github-actions/trigger-travis-macos.sh
This script requires the TRAVIS_COM_TOKEN
variable to be present
in the environment.
The test results are available from Travis CI.
To download the pre-released archive for the specific platform and run the tests, use:
git -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git pull
xpm run install -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git
xpm run test-pre-release -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git
For even more tests, on each platform (MacOS, GNU/Linux, Windows), download the archive from pre-releases/test and check the binaries.
On macOS, remove the com.apple.quarantine
flag:
xattr -cr ${HOME}/Downloads/xpack-*
On GNU/Linux and macOS systems, use:
.../xpack-mingw-w64-gcc-13.2.0-1/bin/mingw-w64-gcc --version
gcc (xPack MinGW-w64 GCC x86_64) 13.2.0
On Windows use:
...\xpack-mingw-w64-gcc-13.2.0-1\bin\gcc --version
gcc (xPack MinGW-w64 GCC x86_64) 13.2.0
- in
CHANGELOG.md
, add the release date and a message like * v13.2.0-1 released - commit with CHANGELOG update
- check and possibly update the
templates/body-github-release-liquid.md
- push the
xpack-develop
branch - run the xPack action
trigger-workflow-publish-release
The workflow result and logs are available from the Actions page.
The result is a draft pre-release tagged like v13.2.0-1 (mind the dash in the middle!) and named like xPack MinGW-w64 GCC v13.2.0-1 (mind the dash), with all binaries attached.
- edit the draft and attach it to the
xpack-develop
branch (important!) - save the draft (do not publish yet!)
- check and possibly update the
templates/body-jekyll-release-*-liquid.md
(use https://gcc.gnu.org/releases.html for the GCC release details, and https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=binutils&submit=Search%21&idxname=info-gnu&max=20&result=normal&sort=score for the binutils announcement) - run the xPack action
generate-jekyll-post
; this will leave a file on the Desktop.
In the xpack/web-jekyll
GitHub repo:
- select the
develop
branch - copy the new file to
_posts/releases/mingw-w64-gcc
If any, refer to closed issues.
- commit the
develop
branch ofxpack/web-jekyll
GitHub repo; use a message like xPack MinGW-w64 GCC v13.2.0-1 released - push to GitHub
- wait for the GitHub Pages build to complete
- the preview web is https://xpack.github.io/web-preview/news/
- go to the GitHub Releases page
- perform the final edits and check if everything is fine
- temporarily fill in the Continue Reading » with the URL of the web-preview release
- keep the pre-release button enabled
- do not enable Discussions yet
- publish the release
Note: at this moment the system should send a notification to all clients watching this project.
- check and possibly update the output of
tree -L 2
in README - check and possibly update the output of the
--version
runs in README-MAINTAINER - commit changes
- open the
package.json
file - check if the links in the
bin
property cover the actual binaries - if necessary, also check on Windows
- select the
xpack-develop
branch - run the xPack action
update-package-binaries
- open the
package.json
file - check the
baseUrl:
it should match the file URLs (including the tag/version); no terminating/
is required - from the release, check the SHA & file names
- compare the SHA sums with those shown by
cat *.sha
- check the executable names
- commit all changes, use a message like package.json: update urls for 13.2.0-1.1 release (without v)
- select the
xpack-develop
branch - check the latest commits
npm run git-log
- update
CHANGELOG.md
, add a line like * v13.2.0-1.1 published on npmjs.com - commit with a message like CHANGELOG: publish npm v13.2.0-1.1
npm pack
and check the content of the archive, which should list only thepackage.json
, theREADME.md
,LICENSE
andCHANGELOG.md
; possibly adjust.npmignore
npm version 13.2.0-1.1
; the first 4 numbers are the same as the GitHub release; the fifth number is the npm specific version- the commits and the tag should have been pushed by the
postversion
script; if not, push them withgit push origin --tags
npm publish --tag next
(usenpm publish --access public
when publishing for the first time; add thenext
tag)
After a few moments the version will be visible at:
Run the xPack action trigger-workflow-test-xpm
, this
will install the package via xpm install
on all supported platforms.
The tests results are available from the Actions page.
- merge
xpack-develop
intoxpack
- push to GitHub
When the release is considered stable, promote it as latest
:
npm dist-tag ls @xpack-dev-tools/mingw-w64-gcc
npm dist-tag add @xpack-dev-tools/mingw-w64-gcc@13.2.0-1.1 latest
npm dist-tag ls @xpack-dev-tools/mingw-w64-gcc
In case the previous version is not functional and needs to be unpublished:
npm unpublish @xpack-dev-tools/mingw-w64-gcc@13.2.0-1.1
- in the
master
branch, merge thedevelop
branch - wait for the GitHub Pages build to complete
- the result is in https://xpack.github.io/news/
- remember the post URL, since it must be updated in the release page
- go to the GitHub Releases page
- check the download counter, it should match the number of tests
- add a link to the Web page
[Continue reading »]()
; use an same blog URL - remove the tests only notice
- disable the pre-release button
- click the Update Release button
- in a separate browser windows, open TweetDeck
- using the
@xpack_project
account - paste the release name like xPack MinGW-w64 GCC v13.2.0-1 released
- paste the link to the Web page release
- click the Tweet button
- go to https://github.com/xpack-dev-tools/pre-releases/releases/tag/test/
- remove the test binaries
Run the xPack action trigger-workflow-deep-clean
, this
will remove the build folders on all supported platforms.
The results are available from the Actions page.