Aspenware offers releases approximately every 4 weeks. For more details on our release processes and methodology, see https://hub.aspenware.net/main/Aspenware-Release-and-Update-Process.1385824260.html.
Upgrade Guidelines
Customers should not fall further than 4 releases behind in their production code at any time. Not staying on current versions can result in the lack of resolution of bugs, errors, and other issues with Aspenware products.
Production environments will not be updated without first notifying and seeking consent from the customer. This raises the importance of customer contact availability - see customer expectations section below.
Before scheduling a release to production, customers are expected to smoke test and approve the code version for their production environment. All functionality that is unique to the customer and not widely adopted should be tested by the customer with each upgrade. For example, if you use subscriptions these should be specially tested with each upgrade.
We offer scheduled release timelines within business hours and do not offer routine releases outside of Business Hours or on Fridays.
If you are integrating with Aspenware’s Headless Commerce APIs, your development team may be required to coordinate with during upgrades. This should only be true if there are breaking changes introduced with a version. If there are no breaking changes, you should follow the same processes outlined here. Your Aspenware representative will provide guidance on whether an upgrade has a breaking change to the APIs.
Customer Expectations During Upgrades
To ensure that Aspenware has the ability to reach out to customer contacts in the case of emergencies and for code upgrades, customers must provide Aspenware with the following emergency contacts:
Role | Name | Work Phone | Cell Phone (only for emergencies) | |
Primary Contact | ||||
Secondary Contact | ||||
Accounting Contact (who has access to the payment gateway) | ||||
IT Contact |
These defined contacts are determined as release decision-makers and stakeholders. Permission to turn sites from maintenance mode to live mode following a deployment must be granted by one of these contacts, otherwise, the site will remain under construction until permission has been granted.