Files.com SDK versions use a structured approach that allows for both stability and innovation. This lets you confidently integrate Files.com functionality into your applications while maintaining control over updates.

Files.com itself relies on several of its SDKs within its internal applications. This means that our SDKs are not only designed for external use but also actively maintained and tested within our own systems. It also means that new versions are released continuously as we release new improvements and features.

Files.com SDK Versioning

Files.com SDKs follow a three-part semantic versioning system in the form of MAJOR.MINOR.BUILDNUMBER , resulting in version numbers such as 1.4.221 or 1.3.0.

Each part of the version number has a specific meaning. MAJOR or MINOR changes may introduce breaking change. Any time a new version has a different MAJOR or MINOR number than what you have currently deployed, you should review the changes before upgrading. Changes to the BUILDNUMBER reflect bug fixes, performance improvements, or new functionality that does not introduce breaking changes, and it is generally not disruptive to update SDK versions when only the BUILDNUMBER has changed.

Use The Most Current SDK Version

Your projects should use the most current version of the Files.com SDK possible. When you contact our support team for help with your code, this will always be the first suggested troubleshooting step because improvements and fixes to the SDKs are released continuously.

Identifying Differences Between SDK Versions

Each SDK is released on GitHub, along with the appropriate package managers. Releases are tagged with version numbers. Using GitHub’s compare feature, you can review differences between two versions to determine if any parts of an SDK that you make use of have changed.

This tool helps developers track modifications, assess risk, and determine whether an upgrade is necessary for their use case.

The URL for comparing differences between between versions of an SDK is:

https://github.com/Files-com/<SDK>/compare/<OLD VERSION>...<NEW VERSION>

Replace the <SDK> with the appropriate repository name for your SDK, either files-sdk-dotnet, files-sdk-go, files-sdk-java, files-sdk-javascript, files-sdk-php, files-sdk-python, or files-sdk-ruby.

Replace <OLD VERSION> with the tag matching your current version of the SDK and <NEW VERSION> with the tag matching the release you want to replace it with.

For example, to compare the differences in the Python SDK from version 1.4.99 to 1.4.222, the final URL would be:

https://github.com/Files-com/files-sdk-python/compare/v1.4.99...v1.4.222

Best Practices for SDK Upgrades

New versions of the official Files.com SDKs are published regularly. These may provide better performance, or access to new features. We encourage you to make use of recent versions of SDKs to facilitate support interactions and ensure you're getting the full benefit of our SDKs.

There are some best practices for dealing with changed versions of your SDKs in order to balance the benefits of getting the most up-to-date SDK with confidence that your critical bespoke code will continue working.

Manage Changes With Pinned SDK Versions

Pinning versions of dependencies used by your code (such as the Files.com SDKs) means that updates to those dependencies will not be applied automatically. This prevents unexpected changes from affecting production environments and gives you full control over when to introduce new versions.

The method for pinning changes will vary by your language, but we recommend pinning the minor version for most customers. For example, this could allow an SDK to automatically update from version 1.2.3 to 1.2.4, but not from 1.2.3 to 1.3.0.

When an SDK is published with a new major or minor version, you can compare the differences to identify whether the new version will require any changes to your code.

Testing SDK Updates in a Staging Environment

If you're relying on a custom solution using a Files.com SDK for an important workflow, maintaining a separate testing or staging environment is crucial. This will allow you to verify that your code (or to the dependencies of your code) will continue to work when changes are made. Depending on what your custom code does, a staging environment might connect to your main Files.com site or to a separate child site.

Having a staging workflow helps you identify any compatibility issues or breaking changes before rolling out updates to live systems.