Vix.cpp v2.9.0

Author: GaspardKirira

vix-site/src/content/blog/changelog/v2.9.0.md

@@ -1,20 +1,20 @@
 ---
 title: "Vix.cpp v2.9.0"
-description: "Vix.cpp v2.9.0 clarifies responsibility across the build system, networking, SDK packaging, and mobile platform support."
+description: "Vix.cpp v2.9.0 clarifies ownership across the build system, dependency management, networking, SDK packaging, and mobile platform support."
 date: 2026-09-17
 ---
 
 # Vix v2.9.0
 
-Vix v2.9.0 is a release about ownership.
+Vix.cpp v2.9.0 is a release about ownership.
 
-As Vix has grown, several parts of the system had started doing work that belonged somewhere else. The build layer reconstructed information already owned by CMake and Ninja. SDK consumers could inherit machine-level requirements for dependencies that existed only because a Vix module used them internally. An asynchronous HTTP API still had places where the underlying work was not consistently asynchronous. Mobile support risked becoming useful only if Vix tried to replace the native toolchains that already understand Android and iOS best.
+As Vix has grown, several parts of the system had started doing work that belonged somewhere else. The build layer reconstructed information already owned by CMake and Ninja. Dependency management needed a clearer separation between what a project requests and what was actually resolved. SDK consumers could inherit machine-level requirements for dependencies that existed only because a Vix module used them internally. An asynchronous HTTP API still had places where the underlying work was not consistently asynchronous. Mobile support risked becoming useful only if Vix tried to replace the native toolchains that already understand Android and iOS best.
 
 v2.9.0 addresses these problems by making the boundaries clearer.
 
-Vix should own project intent, modules, dependency selection, toolchain configuration, diagnostics, and the developer experience. Build backends should own the concrete compilation graph and incremental execution. Internal dependencies should remain internal when Vix can reasonably package them. Platform capabilities should remain platform capabilities. An asynchronous API should stay asynchronous across the entire operation.
+Vix should own project intent, dependency intent, dependency resolution, toolchain configuration, diagnostics, and the developer experience. Build backends should own the concrete compilation graph and incremental execution. Internal dependencies should remain internal when Vix can reasonably package them. Platform capabilities should remain platform capabilities. An asynchronous API should stay asynchronous across the entire operation.
 
-The result is a release that removes unnecessary work from the normal development loop, strengthens the networking stack, makes SDKs more self-contained, and adds practical Android and iOS project support without hiding the native platforms underneath.
+The result is a release that removes unnecessary work from the normal development loop, makes dependency resolution more reproducible, strengthens the networking stack, makes SDKs more self-contained, and adds practical Android and iOS project support without hiding the native platforms underneath.
 
 ## Build: let each layer own the work it understands
 
@@ -50,6 +50,86 @@ The principle behind these changes is simple:
 
 > Vix should add value to the build, not add work to the build.
 
+## Dependencies: Vix can manage dependencies for CMake projects
+
+A project should not have to replace its build system just to get a better dependency workflow.
+
+v2.9.0 significantly expands `vix install` around that idea.
+
+Vix dependencies can now be added directly from Git repositories and used by ordinary CMake projects. The project can keep its existing `CMakeLists.txt` and native CMake targets while Vix manages dependency intent, resolution, locking, integrity, and local materialization.
+
+For example:
+
+```bash
+vix install https://github.com/vixcpp/async \
+  --tag v1.2.1 \
+  --target vix::async
+```
+
+The dependency becomes part of the project manifest:
+
+```toml
+[dependencies.async]
+git = "https://github.com/vixcpp/async"
+tag = "v1.2.1"
+target = "vix::async"
+```
+
+Vix then resolves that request to an exact revision and records the reproducible result in `vix.lock`, including the resolved commit and package integrity metadata.
+
+This creates an important separation:
+
+- `vix.app` describes what the project requests
+- `vix.lock` records the exact dependency graph that was resolved
+
+A project can therefore express a human-readable dependency such as a Git tag while still reproducing the exact commit selected at resolution time.
+
+Dependencies are materialized through Vix's local package store and exposed back to the project through generated CMake integration. Vix can also understand exported CMake targets, subdirectories, header-only packages, CMake options, and transitive dependency relationships.
+
+The important part is that CMake remains CMake.
+
+A project can continue to define its library normally:
+
+```cmake
+add_library(vix_stress STATIC ...)
+
+target_link_libraries(
+  vix_stress
+  PRIVATE
+    vix::requests
+    vix::async
+)
+```
+
+while Vix takes responsibility for obtaining and resolving the packages that provide those targets.
+
+Vix Stress already uses this model. It remains a standalone CMake project while declaring Vix dependencies separately:
+
+```toml
+[dependencies.async]
+git = "https://github.com/vixcpp/async"
+tag = "v1.2.1"
+target = "vix::async"
+
+[dependencies.requests]
+git = "https://github.com/vixcpp/requests"
+tag = "v1.2.1"
+target = "vix::requests"
+
+[dependencies.tests]
+git = "https://github.com/vixcpp/tests"
+tag = "v0.1.1"
+target = "vix::tests"
+```
+
+The lockfile records exact commits and integrity metadata for those dependencies, making the installed graph reproducible rather than merely remembering a floating repository reference.
+
+The goal is not to make CMake projects stop being CMake projects.
+
+The goal is to give them a simpler dependency contract:
+
+> Describe what the project needs, lock what was resolved, and let Vix materialize it.
+
 ## Requests: asynchronous from beginning to end
 
 An asynchronous HTTP API is only truly asynchronous if the entire request path remains asynchronous.
@@ -167,6 +247,8 @@ Many of the changes in v2.9.0 come from the same observation: complexity grows w
 
 If Vix and Ninja both maintain the incremental compilation graph, one of them is doing unnecessary work.
 
+If Vix resolves a project dependency but the build system still has to rediscover where it came from and what exact revision was selected, ownership is unclear.
+
 If Vix bundles an implementation dependency but the consumer must still install and configure that same dependency independently, ownership is unclear.
 
 If an API is called asynchronous but part of its internal path blocks, its abstraction and its behavior disagree.
@@ -177,11 +259,36 @@ v2.9.0 reduces those overlaps.
 
 Vix still does a lot, but the goal is not for Vix to own every part of the machine. The goal is for Vix to own the parts where it can provide a simpler, more reliable programming model, and compose correctly with the parts that already have a clear owner.
 
+## What's next: Vix 3
+
+v2.9.0 closes an important chapter for Vix 2.
+
+Many of the changes in this release came from looking again at decisions that were reasonable when Vix was smaller, but became harder to justify as the project grew. The duplicated build work, dependency ownership, SDK boundaries, and the relationship between Vix abstractions and native platforms are all examples of lessons that will influence the next major version.
+
+The next step is Vix 3.
+
+Vix 3 is not intended to be a larger collection of modules or another layer of abstractions. It is an opportunity to revisit the foundations of Vix with the implementation experience gained from Vix 2.
+
+The goal is to reduce the number of concepts users need to understand, make the remaining concepts more composable, and move complexity into places where Vix can own it reliably.
+
+That means questioning assumptions that have accumulated over time: how projects describe what they need, how dependencies are owned and distributed, where the boundary between Vix and the C++ toolchain should live, and which parts of common C++ development can be made simpler without hiding the language or the machine.
+
+Some of the work in v2.9.0 already points in that direction.
+
+The build system now has clearer ownership boundaries. `vix install` separates dependency intent from reproducible resolution and can integrate those dependencies into existing CMake projects. SDK dependencies are becoming capabilities rather than machine setup instructions. Installed artifacts are treated as part of the public contract. Platform integrations preserve the native systems underneath them instead of trying to replace them.
+
+Vix 3 will continue from those principles.
+
+Its design is still being worked out, and early ideas should not become promises before they have been properly tested. The objective is not to add features for the sake of a major version number.
+
+It is to take what Vix has taught us so far and use it to build a smaller, clearer, and more durable foundation for what comes next.
+
 ## Summary
 
-Vix v2.9.0 improves four major areas:
+Vix v2.9.0 improves five major areas:
 
 - the ordinary build path does less duplicated work and leaves incremental execution to CMake and Ninja
+- `vix install` can manage reproducible Git dependencies for existing CMake projects through `vix.app` and `vix.lock`
 - `vix::requests` has a stronger fully asynchronous path, connection reuse, and streaming response support
 - SDKs are more self-contained and more faithful to the capabilities users actually select
 - `vix::ui` can generate and drive practical Android and iOS projects while preserving native toolchains
@@ -190,4 +297,4 @@ The release also strengthens the installed SDK as a tested public contract rathe
 
 More broadly, v2.9.0 is less about making Vix own more of the system and more about making it own the right parts of the system.
 
-That direction will continue to shape how Vix evolves.
+That direction will continue into Vix 3.