<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Workspaces on VisorCraft News</title><link>https://www.visorcraft.com/news/tags/workspaces/</link><description>Recent content in Workspaces on VisorCraft News</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Tue, 01 Sep 2026 06:00:00 -0500</lastBuildDate><atom:link href="https://www.visorcraft.com/news/tags/workspaces/index.xml" rel="self" type="application/rss+xml"/><item><title>Self-contained Rust workspaces: one repo per app, not one repo per crate</title><link>https://www.visorcraft.com/news/2026/09/self-contained-rust-workspaces/</link><pubDate>Tue, 01 Sep 2026 06:00:00 -0500</pubDate><guid>https://www.visorcraft.com/news/2026/09/self-contained-rust-workspaces/</guid><description>&lt;p&gt;When a codebase grows past the point where one binary crate and a &lt;code&gt;src/&lt;/code&gt; directory can hold it, the reflex most of us were trained with is to split along library lines and give every crate its own repository, its own version number, its own release process, and its own CI pipeline, and the pitch always sounds tidy until the first time one logical change has to land as four pull requests in four repos merged in dependency order while CI matrices multiply in the background. I spent enough of the 2000s doing that dance with CPAN-style per-module distributions and PEAR packages to have a standing allergy to it, so when Cargo offered the opposite bet, one repository per application with every crate that application needs living inside it, both Grexa and Arte-Ogre took it, and the interesting part is not the bet itself but the specific mechanics that make it stay pleasant a year and many thousands of lines later.&lt;/p&gt;</description></item></channel></rss>