Choosing Between Fixed and Floating NuGet Versions in .NET Solutions
Guidance on selecting fixed or floating NuGet versions, using Central Package Management and lock files for reproducible builds.
Loading…
ReadMeFeed / Community knowledge
#versioning
Real questions. Useful conversations. Find the people who know your stack.
dotnet
nugetKeeping Read the Docs Versions Under Control with Automation Rules
Read the Docs turns every tag into a potential published version. Use automation rules, active/hidden flags, and redirects to keep the version picker clean and builds under control.
readthedocsChoosing a Versioning Strategy for Read the Docs: Branches vs Tags in Practice
Read the Docs versions map to Git refs, not semantic versions. This post walks through choosing between branch-per-release and tag-per-release strategies, shows how to pin "stable" to a major series, and lists the limitations (build minutes, private repos, custom domains) that affect real projects.
Single Version or Multiple Versions on Read the Docs: A Decision Guide
Decide between single-version and multi-version docs on Read the Docs: constraints, trade-offs, a comparison table, a .readthedocs.yaml example, and verification steps.
How to Enable Automatic Versioned Docs on Read the Docs with .readthedocs.yaml
Learn how to let Read the Docs automatically build and serve each Git tag or branch as a separate documentation version using a simple .readthedocs.yaml file. Follow the step‑by‑step guide, example config, and common pitfalls to get versioned docs up and running quickly.
Shipping Docs for Every Release: How Read the Docs Handles Version Switching
Read the Docs builds a separate docs site per Git tag or branch. Here's how version switching works, why tag naming discipline matters, and how to add a maintenance-branch version safely.
Choosing the Right Default Version for Your Read the Docs Project
Learn how to pick the default version in Read the Docs so visitors see the right docs for stable releases while developers can still access the latest build.
Pin Read the Docs builds and versions to stop docs drift
Pin the build environment in readthedocs.yml and map repository tags to Read the Docs versions to keep documentation reproducible and aligned with releases.
Devicon and PostCSS integration: class name stability across major versions
When integrating Devicon with a PostCSS‑based build pipeline, the goal is to maintain reliable icon display across project updates without unexpected breakage. Devicon adheres to semantic versioning, where a major release can alter or drop icon class names such as devicon-git-original . PostCSS tools (e.g., cssnano, purgecss) may remove classes that are not
postcss