wechat-windows-versions: keeping an hourly archive of the WeChat installer

An hourly job that keeps the installers

This project uses GitHub Actions to automatically check for updates every hour, download the latest version of the WeChat installer, and push it to the Releases section of the repository.

That one sentence describes the entire mechanism, and it is worth noticing how much of the design is delegated. There is no server, no storage bucket and no database: the repository's Releases section is the store, the Actions runner is the worker, and the release workflow is the scheduler. The badges in the README show the release workflow status and the download counts for all assets and for the latest release, so the archive's health and its popularity are both visible from the front page.

The audience is narrow and specific. It is anyone who needs a specific WeChat for Windows installer at a specific moment, which is a different need from installing WeChat. An administrator who wants to pin a version across a fleet, a researcher assembling a timeline of how the client changed, or a user whose update broke their setup and who wants the previous build back, all need somewhere the old installers still exist.

That need exists because vendor download pages are not archives. Once a new version is published, the old installer is usually gone, and the only record is a third party who kept one.

GitHub Releases as the storage layer

Using GitHub Releases as the backing store for a binary archive is the central design decision, and it explains most of the project's shape.

A release asset is a file attached to a tag, with a stable URL and no size limit worth worrying about for an installer. Each new WeChat version becomes a new tag, and the tag name carries the WeChat version number. Recent tags show the pattern clearly, with v4.1.15.9 dated 2026-09-15, v4.1.15.53 dated 2026-10-12 and v4.1.15.56 dated 2026-10-19.

The consequence is that the repository's release history is a catalogue of WeChat builds, and anyone browsing the Releases tab is effectively browsing a version history of the client. The download counters in the README badges are also a rough measure of how much the archive is used, which is unusual for a project whose whole purpose is to hold files nobody is supposed to look at.

The second consequence is that the archive inherits GitHub's rules about what may be distributed. The README addresses this directly: the installers belong to their respective owners, the project is for archival purposes only, and it does not modify any files. That is a narrow and honest framing, and it is the piece of the story to understand before deciding whether the archive is appropriate in your context.

Scoop and Cetacea buckets for version metadata

Beyond the downloads themselves, the project offers version info and download links from the Scoop Extras bucket and the Cetacea bucket.

The mechanism matters more than the names here. A package manager bucket is a manifest that says which version of an application is current and where to fetch it. Once the archive knows a version exists, the bucket can point at the archived installer instead of at the vendor page, which means the package manager keeps working after the vendor replaces the file.

That is the difference between an archive and an installer mirror. The archive answers the question of what versions existed. The bucket answers the question of what a machine should install now, and it can answer it against the archive rather than against the vendor's download URL.

Two bucket implementations are referenced, the Scoop one and the Cetacea one maintained in a separate repository. The README lists both, which suggests the author considers the bucket a separate concern from the archiver itself, with the archiver as the source of truth and the buckets as consumers.

Official releases only, with betas elsewhere

Only official release updates are tracked, and the README redirects anyone looking for beta versions to a Telegram channel, Telegram@wechat_updatelog.

That boundary is a deliberate scope decision and it has consequences for anyone planning to rely on the archive. An official release is the version the vendor considers stable, and the archive captures the moment it appears. A beta is a different thing with a different URL and a different lifecycle, and it is not what this project collects.

For most users that restriction is an advantage. Official builds are the ones an administrator is willing to roll out to a fleet, and capturing betas would change the character of the archive from a record of shipped software into a stream of unreleased builds.

For users who genuinely need betas, the split is simply a different workflow, with the Telegram channel covering that case. It is also a reminder that the archive is not a complete mirror of everything WeChat publishes, so a search for a specific build can come up empty.

The related projects listed in the README fill in the gaps the current archive does not cover. There is a WeChat Windows 64-bit 3.0 archive, a WeChat Windows 32-bit 3.0 archive, and a WeChat Mac 3.0 and 4.0 archive, each in a separate repository. The division of labour across them is by platform and by product line, and the older 3.0 archives are static collections of the version that predates the current 4.x line.

The Python side: httpx, dateutil and a Python 3.14 floor

The repository is small and the packaging metadata describes it accurately:

requires-python = ">=3.14"
dependencies = [
  "httpx>=0.28.1",
  "python-dateutil>=2.9.0.post0",
]

The dependency list tells you what the script does. httpx is the HTTP client, used to talk to the vendor's update endpoint and to fetch the installer. python-dateutil is there to parse and compare the version numbers and release dates that come back, which is the kind of job that needs a real parser rather than string comparison, especially when the version scheme moves from 4.0 to 4.1 with multi digit components.

The requires-python floor of 3.14 is the most consequential line for an adopter. It means the automation is tied to a recent Python release, so anything running it needs a current interpreter, and a system Python on a server or a scheduled runner pinned to an older version will not do.

The rest of the tree matches the size of the job. There is main.py, pyproject.toml, a uv.lock for reproducible resolution, a .python-version file, the two README files in English and Simplified Chinese, the GitHub Actions workflows, and the LICENSE file.

Release tags carry WeChat versions, not tool versions

The pyproject.toml gives the project itself version 0.1.0, while the release tags are WeChat version numbers such as v4.1.15.9 and v4.1.15.56.

That is not an inconsistency, it is the design. The repository's release list is an index of archived WeChat builds, and each tag is created when a new build is captured. The tool's own version does not move with it, because the tool is not what is being released to users of the archive.

It does mean that a tag name carries two pieces of information at once, the WeChat version and, through the tag date, roughly when it was captured. For anyone scripting against the archive, the tag naming is the contract, and it should be read as a WeChat version rather than as a release number for the archiving tool.

The project is also bilingual, with an English README and a Simplified Chinese one, which makes sense for a project whose subject is a Chinese client and whose user base includes both English speaking and Chinese speaking administrators.

Where this archive is the wrong tool

Three situations point elsewhere.

The first is a need for the current installer on a single machine. If you only want the latest WeChat for Windows, the archive adds a hop through a GitHub release asset for no benefit, and it is one more place that can be unavailable at the moment you need it.

The second is a betas requirement. The archive tracks official releases only, and the README points betas elsewhere. An organisation that tracks pre-release builds has to use that channel and accept a different workflow.

The third is a compliance or redistribution question. The installers belong to their respective owners, the project is for archival purposes only and does not modify any files, and the archiving tool's own licence is MIT. Those three statements describe a careful arrangement for keeping a copy for reference, and they are not the same thing as a licence for redistributing the binaries. Anyone planning to publish the captured installers inside their own distribution channel should resolve that question first.

There is also a plain operational point. An archive that depends on a single hourly GitHub Actions run is one workflow file away from going quiet, and the archived history does not tell you that directly. Checking the recent tag dates and the workflow badge is the cheapest way to confirm the archive is still being maintained.

Editorial conclusion

Adopt this project if you maintain Windows machines with WeChat for Windows and need to pin, roll back or audit installers, or if you want the current installer without relying on the vendor's own download page. Do not adopt it as a source of beta builds, since only official releases are tracked, and read the licensing note before redistributing anything it captures. Verify three things first: that the hourly check is still running, which the release workflow badge and the recent tags are there to show; that the Scoop or Cetacea bucket entry points at the version your tooling expects; and the rights question, because the README states the installers belong to their respective owners and that the project is for archival purposes only and does not modify any files. The licence is MIT, the last push was on 2026-10-19, and the newest archived build is v4.1.15.56.

Frequently asked questions

Official sources

1. cscnk52/wechat-windows-versions on GitHub
2. Issues
3. License: MIT
4. README
5. Releases