Internal Library Versioning Strategy and Release Workflow

At our company, we're planning to develop a set of libraries within a mono-repository, with the goal of maintaining a unified version across all of them. This ensures that when teams include our BOM (Bill of Materials), they can confidently add the required libraries—knowing they’ll always be using a consistent version set. We're considering adopting a Trunk-Based Development (TBD) approach. One aspect I'm unsure about is whether it’s reasonable to create a new release (i.e., tag a new version) with every PR that gets merged into main. These libraries are intended for internal use only, and most teams will rely on dependabot to automatically bump versions as needed. A key requirement for us is to follow Semantic Versioning (SemVer), and we’re planning to use automated version detection—for example, via paulhatch/semantic-version@v5.4.0. Do you have any recommendations or best practices to suggest? What are your thoughts on this setup?

Jun 7, 2025 - 03:30

At our company, we're planning to develop a set of libraries within a mono-repository, with the goal of maintaining a unified version across all of them. This ensures that when teams include our BOM (Bill of Materials), they can confidently add the required libraries—knowing they’ll always be using a consistent version set.

We're considering adopting a Trunk-Based Development (TBD) approach. One aspect I'm unsure about is whether it’s reasonable to create a new release (i.e., tag a new version) with every PR that gets merged into main.

These libraries are intended for internal use only, and most teams will rely on dependabot to automatically bump versions as needed.

A key requirement for us is to follow Semantic Versioning (SemVer), and we’re planning to use automated version detection—for example, via paulhatch/semantic-version@v5.4.0.

Do you have any recommendations or best practices to suggest? What are your thoughts on this setup?