Versions

Versioning strategy

Stability ensures that the micro-services, APIs, tools, and learned practices don't become obsolete unexpectedly.

This document contains the practices that are followed to provide you a taxonomy, balanced with stability, ensuring that future changes are always introduced in a predictable way.

DDB follows Semantic Versioning 2.0.0 (opens new window). DDB version numbers have three parts: major.minor.patch. The version number is incremented based on the level of change included in the release.

• Major releases contain significant new features, some but minimal developer assistance is expected during the update. When updating to a new major release, you may need to run update scripts, refactor code, run additional tests, and learn new APIs.
• Minor releases contain important new features. Minor releases are fully backward-compatible; no developer assistance is expected during update, but you can optionally modify your apps and libraries to begin using new APIs, features and capabilities that were added in the release.
• Patch releases are low risk, contain bug fixes and small new features. No developer assistance is expected during update.

Release schedule

You can follow the current team progress (opens new window) for a more detailed overview.

⚠️ Disclaimer: We operate in a dynamic environment, and things are subject to change. The information provided is intended to outline the general framework direction. It's intended for informational purposes only. We may decide to add/remove new items at any time depending on our capability to deliver while meeting our quality standards. The development, releases and timing of any features or functionality of DDB remains at the sole discretion of the DDB team. The road-map does not represent a commitment, obligation or promise to deliver at any time.

Deprecation practices

Sometimes "breaking changes", such as the removal of support for select APIs and features, are necessary. To make these transitions as easy as possible:

• The number of breaking changes is minimised, and migration tools provided when possible.
• The deprecation policy described below is followed, so that you have time to update your apps to the latest APIs and best practices.
• Notifications will be published within the application and yammer groups to identify the associated timeline.

Deprecation policy

• Deprecated features are announced in the changelog, and when possible, with warnings at runtime.
• When a deprecation is announced, the recommended update path is provided.
• Existing use of a stable API during the deprecation period is supported, so your code will keep working during that period.