Introduction
This document outlines the Galileo breaking changes policy, intended to set mutual expectations between Galileo and our clients regarding our APIs, file formats, and protocols.
Overview
Galileo is on a mission to continuously improve the products and services available to our clients. Our goal is to minimize client impacts when introducing enhancements, new product features and capability improvements. However, from time to time, a change may require a client action to prevent existing capabilities from breaking. The purpose of this document is to outline what changes Galileo considers a breaking change versus a non-breaking change, as well as, how we will provide client communication in the event of a breaking change.
Definitions
Non-breaking changes
Non-breaking changes are code changes that are not expected to be disruptive to clients, who can adapt to these changes at their own discretion. Clients should be able to handle these changes without any notice from Galileo.
Example of non-breaking changes
- Adding a new, optional, input field to a request that does not change the behavior of existing fields
- Adding a new required field that has default values
- Adding a new response code for new functionality that does not impact existing response codes
- Adding a new field or data element to an existing response payload returned from Galileo services that does not change the meaning of existing fields
- Adding an optional request header
- Adding a new endpoint
- Removal of an optional request header
- Updating a parameter description
- Updating sequence numbers in accordance with NACHA rules
Breaking changes
Breaking changes are code changes that will require clients to adapt to these changes to avoid potential disruption. Galileo will communicate these changes to clients before rolling out these changes.
Example of breaking changes
- Requiring a new input field
- Making a previously optional input field a required field
- Updating an existing field or data element in an existing response payload returned from Galileo services
- Changing the agreed details of a file exchange (e.g., file name patterns, field widths, field data types, ordering of fields, format changes, adding/removing fields in fixed width files, line endings in ACH files)
- Changes to request/response headers
- Updating existing required product configuration parameters
Communication
We will communicate breaking changes to clients before rolling out these changes. However, if a change is necessary for critical legal, security, or compliance concerns, we will deploy a breaking change without prior notice. For all other breaking changes we will communicate with clients before the release. This communication will include documentation. Clients will be able to complete client validations, in advance of a change to the production environment. Notification will be completed utilizing existing channels, for example, product roadmap, monthly updates and client meetings.