Change management
This page explains how we release changes to the Weavr platform — when changes reach the Sandbox environment, when they promote to Live, and how we communicate them.
Release cadence
Weavr ships planned functionality in two-week cycles. Each release has two dates that matter to you:
- Sandbox date — when the release lands in your Sandbox environment.
- Production date — when the release promotes to your Live environment.
A release goes to Sandbox first and then promotes to Productionsoon after. This window gives you time to validate the release before it reaches your end customers.
| Release type | Sandbox bake window | Advance notice |
|---|---|---|
| Standard release | 1 week | At sandbox release |
| Breaking change | 3 weeks | At least 4 weeks before sandbox release |
Every release is published to our changelog with both dates and a status badge that indicates where the release is in its lifecycle.
Types of changes
Not every change goes through the sandbox-first cycle. We classify changes into three types, each with its own rules.
Standard feature
New features that you can opt in to without modifying existing integration code. These follow the standard cycle: one week in Sandbox, then promotion to Live.
You don't need to take action when a standard feature ships. If you want to use it, you can adopt it on your own schedule.
Breaking change
Changes that require integration work to remain compatible — for example, a removed field, a tightened validation rule, or a new mandatory parameter. Breaking changes are tagged with Breaking change in our changelog and announced before they reach Sandbox.
We hold breaking changes in Sandbox for three weeks before promoting them. This gives you time to:
- Update your integration against the Sandbox environment.
- Run end-to-end tests with the new behaviour.
- Schedule your own production deployment to align with our promotion to Live.
If a breaking change requires you to act before our production deadline, the changelog entry states the deadline and what action to take.
Fixes and patches
Bug fixes that don't change documented behaviour deploy directly to both environments together and don't go through the sandbox-first cycle. We publish them in the changelog for transparency. Typically, they don't require any action from you.
Breaking changes in detail
When a breaking change is planned, the following sequence applies:
- Around 4 weeks before sandbox release — we publish a changelog entry tagged Breaking change describing the change, the action required, and the production deadline. Our customer success team also notifies affected embeddersEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. directly.
- Sandbox release — the change lands in Sandbox. You can integrate against it, but the existing behaviour still applies in Live.
- Three-week bake window — you have three full weeks to integrate, test, and prepare your deployment. The changelog entry shows the planned production date.
- Production release — the change promotes to Live. Your integration must be ready by this date.
If you discover during the bake window that you cannot meet the deadline, contact our support team as early as possible. We cannot guarantee an extension, but we'll work with you to find a path forward.
The production deadline for a breaking change is firm. If your integration is not updated by that date, the change applies to your traffic and previously working calls may start to fail. Plan adoption work into your sprint that aligns with the bake window.
Release freezes and schedule adjustments
We pause non-essential releases during periods where embedderEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. support is reduced or where downstream partners require schedule stability. Common cases:
- Holiday freezes — the end-of-year freeze typically runs from mid-December to early January. The exact window for the current year is published in the changelog.
- National holidays — releases that fall on a Maltese public holiday shift to the next available date.
- Partner-driven adjustments — occasionally a release date moves to align with a downstream partner's release window. When this happens, we update the changelog entry with the new dates and a note explaining the change.
During a freeze, only critical security fixes and urgent incident fixes are deployed. The next regular release resumes the standard two-week cadence.
Where to track changes
| What you want to know | Where to look |
|---|---|
| What's in the next release | Changelog — entries are published when a release reaches Sandbox |
| Whether a release is in Sandbox or Live now | The status badge on each changelog entry — see Tracking release status |
| Upcoming breaking changes | Changelog filtered by Breaking change |
| Live incidents and platform availability | Our status page (linked from the changelog header) |
| A change you can't find or need help with | Our support team |
We strongly recommend subscribing to the changelog feed so you receive new entries — including breaking-change announcements — as soon as they're published.
Tracking release status
Every changelog entry that follows the sandbox-first cycle carries a status badge derived from the release's sandbox and production dates:
- Scheduled — the release is announced but has not yet reached Sandbox. Plan integration work for when the sandbox date arrives.
- In sandbox — the release is live in Sandbox. You can integrate and test against it. The badge shows the planned production date.
- Live in production — the release has promoted to the Live environment and applies to your production traffic.
The badge updates automatically as dates pass — there is no manual lifecycle step on our side. If a sandbox or production date changes, we update the changelog entry with the new dates, and the badge reflects the new schedule.
Deprecation
When a feature is deprecated, we follow this approach:
- The deprecation is announced in the changelog with a Deprecation tag, including the planned removal date and the recommended replacement.
- The deprecated feature continues to work for a minimum of three months after the announcement, unless a regulatory or security requirement forces a shorter window. Where this happens, we explain why in the changelog entry.
- A reminder appears in the changelog approximately one month before removal.
- On the removal date, the feature is removed in a release that follows the standard breaking-change cycle (Sandbox first, three-week bake, then promotion to Live).
Questions
If anything on this page is unclear, or if you need to confirm how a specific change applies to your integration, contact our support team.