Cloud API Change Notification Policy#
Melissa knows that no-one likes to have to update their code and push out an update at someone else’s schedule. However, we also all live in a fast-changing technological world where changes and updates are often necessary. Our goal is to provide the best user experience possible for our clients while keeping our cloud services as protected and secure as possible.
To make sure the right people receive change notifications:
Make sure your email is registered as a contact with Melissa. Your customer sales representative can assist with that.
Subscribe to opt in to release note update emails: https://releasenotes.melissa.com/subscribe/
Non-Breaking and Return Value Changes#
These are changes that we would reasonably expect not to break any client implementation. They can include things such as:
Adding a response field
Adding new features and options
Regular data or engine updates
Removal of personal information at user request
Occasionally, there could be changes in the values depending on the topic of data being returned and the availability of data.
- Notification Period:
Instant to 3 months
- Notification Channel:
Release Notes, Email Advisory when deemed appropriate
Legacy Only Breaking Changes#
When making updates and changes, we are often updating our components to the latest most efficient and most secure versions. However, there is the possibility of breaking users who are on legacy technology. Examples are:
Removing support for TLS 1.0 after most of the industry has already done so
Removing support for deprecated languages/technologies/toolkits
Updating older HTTP Header values
Melissa will not always know if there will be impact from our changes as we do not know what technologies our clients use at all times. However, risk assessment is performed to reasonably predict any impact our changes might affect. Older technology or severely outdated/insecure versions is at highest risk of impact.
- Notification Period:
3 months minimum, 6 months likely
- Notification Channel:
Release Notes, Email Advisory, Telephone communication
Breaking Changes#
As a last resort, we may need to make a change that would break code compatibility. They may include:
Removing or renaming a response field
Changing the URL
Removal of functionality
We realize our users rely on our services and cannot make changes quickly or easily. This is a last resort for us and we have not pushed out any backwards compatible breaking changes to a major service for the life of our company. It would not be in our interest to do so.
- Notification Period:
6 months minimum, 12 months likely
- Notification Channel:
Release Notes, Email Advisory, Telephone communication
Service Deprecation#
On the small chance that Melissa decides to deprecate a cloud service, we will usually provide an alternative option. That option will likely require changes to client-side code, so we would treat it as a Breaking Change.
- Notification Period:
6 months minimum, 12 months likely
- Notification Channel:
Release Notes, Email Advisory, Telephone communication
Critical Security Changes#
Industry wide critical security advisories are Melissa’s upmost priority and concern. These concerns must be taken care of immediately from a security and compliance standpoint. These may include newly discovered vulnerabilities from major technology providers. As such if a change is deemed to be critical to our infrastructure and operations, we reserve the right to apply fixes and updates at any time without notice. A notice may be provided after the update/patch has been performed. In cases such as these, Melissa’s immediate priority is to get the latest version into production rather than notification. Historically, critical security changes have never impacted end user compatibility for Melissa Cloud Service clients. However, this is not a guarantee.
- Notification Period:
Instant
- Notification Channel:
Release Notes, Email Advisory