We're rolling out improvements to how Cloudsmith evaluates relational version ranges across the platform to ensure clearer and more predictable results for semantic version searches and version-based ordering.

This update improves the accuracy of package listings, policies, deny rules, entitlement restrictions, and searches. In most cases, your existing rules already behaved as expected. These changes primarily refine how we handle edge cases, particularly those related to prereleases.

As we migrate customers across, Cloudsmith will apply stricter and more consistent logic when comparing and ordering versions. This change resolves edge cases where a query like >=1.0 could incorrectly match prerelease versions, such as 1.0-a1.

Relational searches only consider versions that can be parsed and compared as semantic versions.

Version comparisons now follow a single consistent semantic ordering, including prereleases.

When a version cannot be parsed, we fall back to string-based behavior, allowing existing tag-like versions to continue working as before, including labels such as “alpha” and “beta.”

You generally don’t need to change any existing rules or queries, unless you want to maintain previous behavior for prereleases. To do so, you can use a “lowest possible” prerelease version as part of your search term, such as:

prerelease versions in <1.0 or <=1.0 searches, use <1.0-a or <=1.0-a instead.

prerelease versions in >=1.0 searches, use >=1.0-a instead.

We're rolling this out to organizations in stages to ensure a smooth transition across the platform. If you haven't seen the change yet, your organization will be migrated across in the coming weeks. Want early access? 

This new functionality represents a positive behavioral change. It makes version comparison and ordering more reliable, reducing corner-case surprises. It also brings version queries closer to standard semantic version expectations.

If you use complex constraints or prerelease handling, the results may appear more specific than before. If anything appears differently than you expect, or if you would like to confirm how a specific query is handled, please reach out, and we can review it with you.

Version handling improvements

We've improved our versioning logic to accurately handle the parsing and semantic sorting of versions with prerelease components. 🛠

Previously, our implementation treated all numbers in prerelease components as a single integer when comparing versions.

 would be converted into single integers, 

, then compared. This naive parsing led to incorrect sorting, as 

, marking the wrong version as the latest.

With this recent update, we individually parse and compare each numerical part of the prerelease components within a version. In the same example, 

 is correctly determined to be the latest version.

This improvement aligns our handling more closely with the 

, resulting in more precise and accurate sorting for versions with a prerelease component and better consistency when we need to automatically determine a package's "latest" version tag.

Whether you have existing packages with prerelease components or are uploading new packages, this update ensures more accurate version comparisons and sorting. 📝

For existing packages with prerelease components in the version:

They’ll retain their existing parsed versions with no automatic changes.

The version will be parsed with the new logic if the package is resynced.

You’re in control to choose whether to resync or retain existing versions.

For newly uploaded packages with prerelease components in the version:

They will automatically use the new logic to parse versions correctly.

The more accurately parsed versions with prerelease components will impact the determination of the “latest” version tag for packages (relative to other prereleases).

If you have a mixture of old and new packages and notice that the ordering isn’t correct, you’ll need to resync the old packages first, as above.

If you have any questions or concerns about this change, 

 and we’d be happy to have a chat. 🗯

Semantic sorting for prerelease versions fixed

We are excited to announce a significant enhancement to the 

 endpoint in our system. This update specifically addresses and significantly reduces caching issues (staleness) when fetching the latest version of raw package files.

 When you requested package files from our Content Delivery Network (CDN), these files were subject to a caching time of 3600 seconds (1 hour). If you updated a package file, the latest version would not be immediately accessible. The endpoint would continue serving the file's cached (and therefore stale) version for up to an hour.

 We have now modified this behavior. The 

 endpoint will no longer serve cached files. Instead, it will redirect to the file's actual, current location. This change ensures that you consistently access the most recent version of a file without the previous delay.

 For instance, if you hosted version 1.0 of a raw package file and then updated it to version 2.0, the latest endpoint would have continued to return the 1.0 version for at least 1 hour under the old system. With this enhancement, your first request will be redirected to the 1.0 file, and any subsequent requests (after the update) will be redirected to the 2.0 file.

Note / Action Required – Client Configuration:

 This enhancement relies on your client's ability to follow redirects. If you are using tools like 

 flag, you might encounter issues, such as the appearance of downloading an empty file. To fully benefit from this update, please ensure your tooling is configured to follow redirects.

Thank you for your continued support. We are always here to assist with any questions or feedback regarding this update.

Immediate Access to Latest Raw Package Versions

Small tweak to make python upstream indexing more robust.

Resolved minor bugs in helm upstream package parsing logic.

Minor upstream bug fixes

Fixes to Maven upstream (or as we like to describe it, a minor 

 constraint to the log export query, ensuring there is more control over exports.

Maven Upstreams and Export Fixes

Fixed an issue that affected quarantine upstream for python packages.

Fix for Python upstream packages

Ensure docker digests don't change when copying.

Farewell, Python 2, with your legacy code, You paved the path for the current abode. Though you’re now outdated, and we’ve bid you adieu, In the annals of coding, we'll always value you

Docker fixes, and goodbye to Python 2

Because little wins should also be celebrated, today's release notes includes a fix to 

allow Terraform to authenticate with a JWT.

Terraform Bug Fix

Remove exception log when parsing Cocoapods metadata

Improved internal handling of errors on Terraform

Fixes to Maven package sync with different versions being seen as duplicates

Switched to using detached signatures for signature verification of Debian upstreams.

Cocoapods, Terraform, Maven and Debian bug fixes

Updates to our Terraform metadata parsing to handle variables without a type attribute

Updates the submodule providers serialization to handle multiple providers correctly

Allow Docker login to use JWT token generated from OIDC exchange

Checks to ensure Cocoapods package metadata has a license

Cloudsmith Changelog