Publishing & Releasing CURD

When you build CURD and want to distribute it to the world, the process involves two main steps: GitHub Releases (the source of truth) and Package Manager Registries (the distribution channels).

Here is the exact workflow for taking the output of make dist and publishing it globally.

1. GitHub Releases (The Source of Truth)

All native package managers (Homebrew, Winget, Scoop, AUR) do not host the binary themselves. They read a manifest file that points to a download URL on GitHub Releases.

Therefore, your first step is always uploading the binaries to GitHub.

1. Run the Build: Execute make dist (typically done in a Linux/macOS GitHub Actions CI runner to avoid local cross-compilation linker issues).
2. Create a Tag: git tag v0.7.1-beta && git push --tags
3. Upload to Release: Go to your GitHub repository -> Releases -> “Draft a new release”.
4. Attach Artifacts: Upload all the .tar.gz, .zip, .deb, and .rpm files from the dist/cli/ directory.

2. Pushing to Language Registries (PyPI & NPM)

Language registries actually host the built artifacts, so you upload directly to them.

PyPI (curd-python)

The make dist-python command generates Python wheels (.whl files) inside dist/python/. To publish them to PyPI:

# Install twine
pipx install twine
 
# Upload all wheels
twine upload dist/python/*.whl

(Once uploaded, users can instantly run uvx --from curd-python curd)

NPM (curd-node)

The make dist-node command generates a .tgz tarball and native .node bindings. To publish to NPM:

cd curd-node
npm publish --access public

3. Submitting to Native Package Managers

Once your GitHub Release is live with the attached binaries, you can update the package managers using the manifests generated in dist/package-managers/.

Homebrew (macOS / Linux)

1. Copy the dist/package-managers/homebrew/curd.rb file.
2. Commit it to your custom tap repository (e.g., github.com/aerospeedsta/homebrew-curd).
3. If you want it in the official homebrew-core, you must open a Pull Request to Homebrew/homebrew-core with this formula.

Arch Linux AUR (curd-bin & curd-git)

Arch Linux users use the AUR.

• curd-bin: Uses the pre-compiled binary from GitHub. The make dist-arch command generates a .SRCINFO and PKGBUILD. You clone the AUR ssh repo ssh://aur@aur.archlinux.org/curd-bin.git, copy the generated files in, run makepkg --printsrcinfo > .SRCINFO, and git push.
• curd-git: This compiles from source on the user’s machine. You manage this in a separate AUR repo curd-git.git with a PKGBUILD that runs cargo build.

Winget (Windows)

The Windows Package Manager uses YAML manifests.

1. Take the manifest generated in dist/package-managers/winget/.
2. Open a Pull Request to the official Microsoft registry: github.com/microsoft/winget-pkgs.
3. Use their provided wingetcreate CLI tool to automatically submit the PR.

Debian/Ubuntu (APT) & Fedora (DNF)

For these platforms, you generally host your own apt/yum repository (using a tool like reprepro or Cloudsmith), or simply tell users to download the .deb and .rpm files directly from your GitHub Releases page, as we documented in the Setup guide.

Conda-Forge

To get CURD into the conda-forge channel:

1. Ensure your source code is tagged and released on GitHub.
2. Fork the staged-recipes  repository.
3. Create a new recipe recipes/curd/meta.yaml that points to the GitHub source tarball (v0.7.1-beta.tar.gz) and uses rust as a build dependency.
4. Open a Pull Request. Once merged, Conda-Forge’s CI will automatically build and distribute the binaries to Anaconda users (conda install -c conda-forge curd).

Automating with CI/CD

To make this instantaneous, this entire process is typically automated via GitHub Actions. A standard workflow:

1. Triggers on a v* tag push.
2. Uses a matrix matrix to build x86_64 and aarch64 on Mac, Windows, and Linux runners.
3. Uses softprops/action-gh-release to upload all binaries to the GitHub Release.
4. Uses pypa/gh-action-pypi-publish to push the wheels to PyPI.
5. Uses a custom script to bump the Homebrew Tap repo hash.