How a Release Groups Builds
A Release is a container for related builds. For example, Release 2.14 might contain:
Build v2.14.0 (initial release)
Build v2.14.0-rc1 (release candidate)
Build v2.14.1 (patch)
Build v2.14.2 (patch)
Instead of managing testing against each version separately, you can view Release 2.14 as a whole and see: "How much of Release 2.14 did we test? What's the overall pass rate? Are there uncovered risks?"
Automatic Linking via Version Patterns
To avoid manually assigning every build to a release, you can set up a Version Pattern when you create or edit a release. A version pattern uses glob-style wildcards to match build versions.
Creating a Release with a Version Pattern
Go to Releases > Releases
Click New Release or edit an existing release
Fill in the release name (e.g., "Release 2.14")
Scroll down to the Version Pattern field
Enter a pattern like
2.14.*(matches any build version starting with "2.14.")Click Save
From that moment on, any build you create with a version matching the pattern automatically attaches to that release.
How Pattern Matching Works
The version pattern uses simple wildcard matching:
Pattern | Matches | Does Not Match |
|
|
|
|
|
|
|
|
|
When you create a build with version v2.14.5 and Release 2.14 has the pattern 2.14.*, TestCollab automatically links the build to Release 2.14.
What Happens If Patterns Don't Match
If a build's version doesn't match any release's pattern, it remains unassigned. You can manually assign it later if needed.
If a build's version matches multiple patterns (unlikely but possible), it uses the first matching release.
Manually Assigning a Build to a Release
You can override automatic pattern matching by manually assigning a build to a different release, or assigning an unmatched build to a release.
From the Build Detail Page
Open the build by clicking its version on the Builds list
On the right side, below the deployment or build details, look for the Release row
If you are a Manager or Admin, you see a dropdown menu; click it to select a different release
If you want to unassign the build, select the blank option at the top of the dropdown
What "Manually Assigned" Means
When you override a pattern-matched assignment, TestCollab remembers that you did it manually. On the Builds list, the Linked Release column shows "Manual" next to the release name for manually-assigned builds. This helps you identify which assignments were automatic and which were deliberate overrides.
The Auto-Detach Setting
By default, when you manually assign a build to a release, the assignment sticks even if you later change the build's version so it no longer matches the release's pattern.
However, your project administrator can enable an optional Auto-Detach setting:
Project Settings > General > Auto-Detach Builds on Version Change
If enabled:
A manually-assigned build that no longer matches its release's pattern is automatically detached
For example, if you manually assigned v2.14.0 to Release 2.15, then later changed the version to v3.0.0, it auto-detaches from Release 2.15
If disabled (the default):
Manually-assigned builds stay attached even if their version changes
You must manually unassign them if you want to change the release
Ask your project administrator if this setting is enabled for your project.
Viewing Builds in a Release
To see all builds in a specific release, go to Releases > Releases, click the release name to open its detail page, and scroll to the Builds in this Release section. You'll see a table of all builds attached to that release, with their versions, environments, and release dates.
See the "Using Releases with Build Tracking" guide for details on the Release Readiness page.
Related Articles
Understanding Builds and Releases - Overview of builds and releases
Creating and Managing Builds - How to manually create builds
Using Releases with Build Tracking - Release Readiness page features and build information
Linking Test Plans to a Build - Link test plans to specific builds within a release