What is Semifold?

Semifold manages versions and releases for a repository that contains packages from more than one ecosystem.

Imagine a product repository with a Rust core library, Node.js bindings, a Python client, and a C++ component. Each ecosystem already has a good package manifest and publishing tool. The difficult part is everything between them:

• deciding which packages need a new version after one change;
• updating internal requirements when a dependency moves;
• keeping one understandable changelog history;
• publishing in an order that respects relationships across languages;
• recovering when one registry succeeds and another fails.

Semifold supplies that repository-wide layer. It does not replace Cargo, npm, Python packaging, CMake, or your registries.

One workspace graph

Every managed package becomes a node in one workspace dependency graph. A node contains:

• a stable PackageId used by configuration and changesets;
• the manifest or registry name used by its ecosystem;
• current version, path, and publishability;
• manifest dependencies and optional explicit relationships;
• the adapter responsible for reading and editing its manifest.

This normalized graph is why a Rust package can affect a Node.js or Python package without pretending their manifests are the same.

Built-in and custom ecosystems

Semifold includes adapters for Rust, Node.js, Python, and C++. They understand the package and workspace formats covered by their implementation and fixtures.

Repository-local JavaScript ecosystem plugins implement the same discovery, inspection, and edit-planning boundary, so custom packages join the same graph instead of living in a separate release script.

The work you do with Semifold

1. Describe the repository

smif init discovers packages and creates .changes/config.toml. The file gives every package a stable ID and records release policy that package manifests cannot express.

As the repository changes, smif config sync compares current discovery with the saved configuration. It updates discovered facts without silently replacing intentional policy.

2. Record a user-visible change

A changeset is a small Markdown file that names affected package IDs, requested version bumps, changelog categories, and a summary. It travels with the code change and can be reviewed before versions move.

---
native-core: "minor:feat"
web-bindings: "patch:fix"
---

Expose the new parser through the web bindings.

3. Update every affected version

smif status shows the direct changes and additional packages affected by dependency rules. smif version then updates package versions, internal requirements, changelogs, and consumed changesets through the adapters responsible for each manifest.

The plan is valuable because it makes the decision reviewable, but the product capability is the consistent cross-ecosystem version update it describes.

4. Publish with ecosystem-specific rules

smif publish orders packages by dependency, checks whether target versions already exist, and runs the configured command for each ecosystem. GitHub Release and asset work can be enabled separately.

The final report distinguishes successful, skipped, failed, and not-started packages. That information lets a maintainer repair credentials or registry configuration and resume without guessing which versions already escaped.

What Semifold deliberately leaves to other tools

Semifold does not build or test your packages, host a package registry, infer product policy from commit messages, or hide credentials inside plugins. Build and test commands remain in your existing tooling or explicit hooks; registry authentication remains in the execution environment.

Learn the vocabulary as you need it

You do not need to memorize every internal term before starting. The glossary explains PackageId, ecosystem adapters, changesets, release channels, registries, and plans with their practical differences.

Next, install Semifold and follow your first release.