This is the official roadmap for the Open Service Broker for Azure (OSBA) project. OSBA is currently available as a stable release and this roadmap represents our plan to continue to evolve (OSBA) and the services it provides.
OSBA releases follow semantic versioning strictly, which means we will not implement backward incompatible changes in a minor or patch release.
This roadmap addresses stability in terms of two dimensions:
- Database Schemas
These aspects of the broker can mature out of step and need to be considered independently. For example, the broker currently uses Redis to store all data and orchestrate asynchronous queues. As the broker matures, we may make changes that require additional information to be persisted for provisioned services or change tablec or collection names. Before the broker has a
v1.0.0 release, these changes may
introduce incompatibilities with previously populated Redis instances.
Once we declare services and our broker have reached preview status, we will begin to ensure backward compatibility for future releases.
See below for more information concerning stability plans for each.
Services and Plans
As services are developed, the plans available and features of the service may change and are not guaranteed to exist in the final stable release. When a service is promoted to stable, we will ensure backward compatibility. Services/Plans have three stability tiers:
Please see stability documentation for information on each of these tiers.
Currently, the following services are 'stable':
By December 2018, we expect to release the following services as 'stable':
We may release other services listed as 'experimental' or 'preview' during this time.
There are two tiers of database schemas to consider:
- General outline: the broker currently uses Redis to store all data and orchestrate asynchronous queues. 'General outline' means the names and arrangement of the "tables" and layout of asynchronous queues
- Individual services: the broker stores provisioning and binding data for each service/plan in a "table" in Redis. Individual services means the layout of each provisioning & binding record. When a service is marked
stable, its individual service schema will be backward compatible.
All releases before
v1.0.0 may introduce backward-incompatible changes to either database schema.
The general outline schema will remain backward compatible within a major release >=
For example, the general outline schema will remain backward compatible between
This follows semver.
The individual service schemas for
stable services will remain backward compatible within
a major release version >=
v1.0.0. For example, the individual service schema for
stable service will remain backward compatible between
The schemas for all
experimental services may change at any time,
possibly in backward incompatible ways.