Software Updates
- Table of Contents
- Describe the software update process.
- Is downtime or queue pausing required for major or minor version updates?
- How frequently are updates needed?
- How frequently are breaking changes deployed?
Describe the software update process.
When deployed on bare metal or a VM, software updates are quite straightforward.
When deployed in a Docker container, simply restart the container.
When running a GreenArrow Cluster of Docker containers or VMs, you can do a zero-effective-downtime version upgrade by staging the restarts of the different containers/VMs in the cluster.
The Kubernetes reference architecture supports zero-downtime version upgrades by performing a rolling-restart of the MTA nodes in the cluster and draining the queues of the old nodes to the new nodes.
Is downtime or queue pausing required for major or minor version updates?
For single instance installations:
Not all GreenArrow-internal microservices are restarted on a version update; only the required ones are. Often the MTA continues to receive incoming email and only pauses deliveries during the upgrade process. Upgrades typically don’t require more than 30 or 60 seconds. This is all handled gracefully within GreenArrow, so the impact of the restarts is minimal.
For cluster or Kubernetes reference architecture installations:
Zero-downtime major and minor version upgrades are supported. See details above.
How frequently are updates needed?
Updates are needed primarily when you want access to a new feature or bug fix, but most GreenArrow customers update approximately monthly. You can update less frequently if you prefer.
We release individual features when they are ready instead of batching releases, which leads to typically a few updates per month. Our change log can give you an idea of how frequently we release updates.
It is also worth noting that we take reverse compatibility very seriously. For example, when we change a default behavior, we add a “legacy behavior” option to maintain the former default behavior, and this option is automatically enabled by the upgrade process. This means that when you upgrade the default behavior you experience does not change.
How frequently are breaking changes deployed?
Breaking changes are exceedingly rare, and are documented in the Change Log.