Vix.cpp v2.7.8

Vix.cpp v2.7.8 introduces first-class support for moving packages between repositories, namespaces, and package names without abandoning their existing registry history.

A package can now continue under a new identity while preserving its published versions, documentation, maintainers, keywords, and repository information. The previous package remains in the registry as a deprecated entry that points developers and package commands toward its replacement.

This release also completes the migration workflow across vix publish, vix add, vix outdated, and vix update. Package moves are no longer only registry metadata; they are understood throughout dependency installation, lockfile generation, version checks, and project updates.

Alongside the registry work, vix publish can now create its registry pull request automatically, dependency-only workspace packages can be published without public headers, and vix build once again supports Vix installations discovered through normal CMake mechanisms when no compatible managed SDK profile is available.

Release focus

Package identities sometimes need to change.

A project may move from a personal namespace to an organization, split one repository into several packages, adopt clearer package names, or transfer ownership to a new team. Before v2.7.8, such a change usually required publishing a separate package and manually explaining that the previous identity should no longer be used.

That approach loses continuity. Existing users may continue installing the old package, dependent projects may retain obsolete identifiers, and the registry presents the replacement as an unrelated project even when both packages share the same source history.

Vix.cpp v2.7.8 treats these changes as migrations rather than independent publications.

The registry records the relationship between the previous and replacement identities. Package commands follow that relationship when resolving dependencies, and project manifests are updated to use the replacement package rather than keeping both names in the dependency graph.

The result is a package move that remains visible and traceable without requiring users to reconstruct the relationship manually.

Package moves and namespace migrations

vix publish can now detect when an existing registry package has moved to a different repository location, namespace, or package name.

For example, a package previously published as:

softadastra/kordex-runtime

can continue as:

kordexjs/runtime

The replacement entry preserves the package history associated with the original project, including:

  • published versions;
  • package metadata;
  • documentation;
  • maintainers;
  • keywords;
  • repository information.

The previous package is not removed from the registry. It is marked as deprecated and receives a movedTo field pointing to the replacement identity. The replacement package receives a corresponding migratedFrom field.

This keeps old links and package references meaningful. A developer who encounters the previous package can still understand where the project moved, while new installations can resolve directly to the maintained identity.

Migration detection during publication

Package moves are detected using repository identity and shared Git history.

Repository URLs alone are not sufficient because repositories themselves can move between owners or organizations. Package names are also not sufficient because a project may deliberately change its namespace or split its publication layout.

By considering both repository identity and Git history, vix publish can distinguish a real project migration from an unrelated package that happens to use similar metadata.

When a move is detected, the publication workflow prepares both sides of the migration:

  • the previous package is updated with its replacement;
  • the replacement package records its previous identity;
  • existing versions and metadata are carried into the new registry entry;
  • the publication commit and pull request describe the move explicitly.

The migration remains part of the normal registry review process. It is represented as a clear change to the registry rather than an invisible redirect controlled only by the CLI.

Automatic registry pull requests

vix publish now creates the registry pull request after pushing the publication branch.

Earlier versions could prepare and push the registry change while still requiring the developer to open the pull request separately. The command could also report a successful publication even when no pull request had been submitted, leaving the registry change incomplete.

The updated workflow performs the complete submission sequence. After the branch is pushed, Vix checks for an existing pull request associated with that branch. If one already exists, it is reused. Otherwise, the command creates a new pull request and displays its URL.

The pull request URL is also included in JSON output, allowing scripts and other tools to track the registry submission without parsing terminal text.

For package migrations, the pull request title and description identify both package IDs. This makes the proposed move understandable during review without requiring maintainers to inspect the registry files individually.

Publication now fails clearly when the pull request cannot be created. This includes cases where the GitHub CLI is unavailable, gh is not authenticated, or GitHub rejects the pull request request.

A pushed branch without a corresponding registry pull request is therefore no longer reported as a completed publication.

Migration support in vix add

vix add now follows the movedTo relationship when a project requests a package that has been migrated.

For example:

vix add softadastra/kordex-runtime

can resolve to:

replaced: softadastra/kordex-runtime -> kordexjs/runtime

The replacement is not added beside the previous dependency. Vix removes the old identity and writes the new package ID into the project configuration.

This applies to dependencies declared in both vix.json and module manifests using vix.module. The old dependency tree is removed before the lockfile is regenerated, preventing packages reachable only through the previous identity from remaining in vix.lock.

The final project state contains the replacement package and the dependency tree required by that replacement.

This behavior is important for direct migrations, but it also applies when an old package appears through another dependency. The resolver can follow package moves while constructing the graph instead of treating the deprecated and replacement identities as separate packages.

Moved packages in vix outdated

vix outdated now reports package migrations separately from ordinary version updates.

A moved package is not considered current merely because the last version published under its old identity matches the installed version. The command follows movedTo, reads the available versions from the replacement package, and compares the project against the package that is still maintained.

The terminal output identifies the replacement:

moved -> kordexjs/runtime

JSON output includes the migration state through the moved and moved_to fields.

This distinction allows developers and automation to separate two different maintenance tasks. An ordinary outdated package needs a version update under the same identity. A moved package requires the project to adopt a different package ID, potentially alongside a newer version.

Package migrations in vix update

vix update can now apply the package identity change directly.

When an old dependency is encountered, the command updates vix.json to use the replacement identity and regenerates vix.lock from the new package graph. Versions and hashes are then read from the replacement lockfile entry rather than from the package ID that was removed during migration.

Migration reporting is also available in dry-run and JSON modes. A project can therefore inspect the planned identity changes before modifying its manifest or consume the migration result through tooling.

The update workflow keeps the manifest and lockfile aligned. It does not leave the previous package name in vix.json while resolving the replacement internally, because that would cause the migration to be repeated on every update and would make the declared project state misleading.

Clean dependency replacement

This release fixes a migration issue where both the previous and replacement package IDs could remain in the project after a move.

That state was especially problematic when the two identities exposed overlapping dependencies. The lockfile could contain duplicate branches, retain transitive packages that were no longer needed, or make it appear that the project intentionally depended on both versions of the same package.

Vix now removes the previous dependency tree before resolving the replacement.

After migration, vix.json and vix.lock contain only the replacement identity and the packages required by its current dependency graph.

Semantic version ordering

Registry version selection now uses semantic version comparison instead of lexical string ordering.

Lexical ordering compares version text character by character, which can produce incorrect results for versions such as:

2.9.0
2.10.0

Under string ordering, 2.9.0 may appear greater because the comparison does not understand version components. Semantic version comparison correctly treats 2.10.0 as the newer release.

This affects package resolution after migrations as well as normal registry operations. When Vix follows a moved package to its replacement, it now selects versions according to their semantic meaning rather than their textual representation.

Workspace packages

vix publish now supports dependency-only workspace packages.

A workspace package can declare:

{
  "type": "workspace"
}

Unlike a library package, a workspace package does not need to expose public headers. Its purpose is to group related dependencies under one package identity so that a complete toolchain, framework distribution, or project environment can be installed as a unit.

For example, a workspace package may depend on runtime, bindings, standard library, and command-line packages without containing a C++ library of its own.

Header validation remains active for packages that publish source code or libraries. The workspace type only changes validation where public headers would not represent the role of the package.

This distinction allows the registry to support aggregate packages without weakening the validation applied to normal C++ packages.

SDK discovery in vix build

Managed SDK profiles remain the preferred way to provide a consistent Vix development environment, but they are no longer required for every project that uses Vix.

Vix can be installed in several valid ways. A developer may use a managed SDK under ~/.vix/sdk, a system package, a local source installation, a custom installation prefix, or an existing Vix installation created before SDK profiles were introduced.

CMake already has established mechanisms for discovering these installations, including:

  • Vix_DIR;
  • CMAKE_PREFIX_PATH;
  • system installation prefixes;
  • Conan and vcpkg toolchains;
  • custom CMake toolchain files.

Previous CLI behavior could stop the configuration before CMake ran when a compatible managed profile was not installed. This prevented projects from using otherwise valid Vix installations that CMake could discover normally.

Vix.cpp v2.7.8 changes that selection process.

When a complete and compatible managed profile set is available, vix build continues to use it automatically. When no suitable managed profile exists, the CLI preserves the project environment and allows normal CMake package discovery to proceed.

A missing managed profile is therefore no longer treated as proof that Vix is unavailable.

Legacy, local, and system installations

Projects using Vix outside ~/.vix/sdk no longer need to run:

vix upgrade --sdk default

simply to pass the CLI configuration stage.

A project can use a system installation:

cmake -S . -B build

or provide an explicit prefix:

vix build -- \
  -DCMAKE_PREFIX_PATH=/opt/vix

It can also rely on an existing Vix_DIR, a package-manager toolchain, or another CMake discovery mechanism already used by the project.

The CLI does not attempt to replace those environments with an incomplete managed profile. It selects the managed SDK only when the profile set is complete and compatible with the requested build.

This preserves the benefits of managed profiles while keeping Vix compatible with normal CMake projects and installations created by earlier releases.

Registry publication fixes

The publication workflow now verifies that the registry pull request was actually created or found before reporting success.

Failures from the GitHub CLI are surfaced directly. The developer receives a clear error when gh is missing, authentication is unavailable, or pull request creation fails for another reason.

Existing pull requests for the same publication branch are reused rather than duplicated. This is useful when a publication command is repeated after a partial failure or when the registry branch was pushed before the pull request step completed.

The resulting output now represents the real registry state: a publication is complete only when its review request exists.

Lockfile lookup after migration

vix update previously regenerated the lockfile using the replacement package identity but could still attempt to read version and hash information through the previous package ID.

Because the old entry no longer existed in the regenerated lockfile, the command could fail after successfully performing the migration itself.

The update workflow now follows the resolved identity throughout the complete operation. Once a dependency has moved, lockfile lookup, version reporting, and hash reporting all use the replacement package ID.

Workspace package validation

Dependency-only workspace packages were previously rejected because the publication validator expected every package to contain public headers.

That rule is appropriate for libraries, but not for an aggregate package whose entire purpose is to declare a group of dependencies.

Validation now considers the package type. Workspace packages can be published without public headers, while source and library packages continue to require the files expected by their publication model.

Validation

Package migration was validated through the Kordex namespace move:

softadastra/kordex-runtime  -> kordexjs/runtime
softadastra/kordex-bindings -> kordexjs/bindings
softadastra/kordex-std      -> kordexjs/std
softadastra/kordex-cli      -> kordexjs/cli
softadastra/kordex          -> kordexjs/kordex

This migration covered both individual packages and a workspace package that aggregates the complete Kordex environment.

Publication tests verified that Vix could identify the shared repository history, preserve the existing registry metadata, create the replacement entries, deprecate the previous identities, and submit the registry pull requests automatically.

Dependency tests covered old package IDs in vix.json, dependencies declared through vix.module, direct dependencies, and packages reached transitively. After migration, the resulting manifests and lockfiles contained only the replacement identities and their required dependency trees.

The vix outdated and vix update workflows were tested in terminal, dry-run, and JSON modes. These checks verified that version information was read from the replacement package and that migration details remained available to scripts.

Workspace publication was validated with packages that provide dependency aggregation without public headers.

SDK discovery was tested with managed profiles, system installations, local installations, custom prefixes, and Vix installations created before managed SDK profiles were introduced. A complete Vix project was also built with the updated CLI module to verify that the fallback to normal CMake discovery did not interfere with standard managed SDK builds.

Compatibility

Existing packages do not need to declare migration metadata manually. Packages that have not moved continue to use the normal publication and resolution workflow.

Old package identities remain present in the registry after migration, so existing references can still produce a meaningful result. Package commands redirect those references to the replacement, while the registry preserves the historical relationship between both names.

Projects using current package IDs are unaffected. Projects using old identities can migrate through vix add or vix update, and vix outdated can report the move before any project files are changed.

Workspace packages introduce an additional package type without changing validation for libraries and source packages.

Managed SDK profiles also remain supported. The discovery change only affects the case where a complete compatible profile is unavailable. In that situation, Vix now allows CMake to use the environment already provided by the project or system.

Release summary

Vix.cpp v2.7.8 gives package identity changes a complete workflow across the registry and CLI.

A project can move to a new repository, namespace, or package name while preserving its published history. The registry records both sides of the move, publication creates the required pull request, and package commands update projects to use the maintained identity without retaining duplicate dependencies.

Workspace packages extend the registry to dependency-only package groups, while semantic version ordering makes version selection reliable for both migrated and ordinary packages.

The SDK discovery changes address a separate compatibility problem. Managed profiles remain available when they are complete, but projects using system, local, custom-prefix, package-manager, or legacy Vix installations can once again rely on normal CMake discovery.

Together, these changes make package moves explicit, reviewable, and practical without narrowing the ways developers can install and build with Vix.