> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/getting-started/release-notes/release-policy.md). # Release Policy The E-commerce Payment Gateway is continuously maintained and enhanced as a managed service. This page explains how upcoming changes are communicated, how you can review and test relevant functionality in advance, and how we indicate when action is required from you. {% hint style="success" %} Upcoming releases are normally announced through a Release Candidate at least one month before the planned release date. The Release Notes in the Documentation Portal are the primary source of information about upcoming and delivered changes. You can also choose to receive release notifications by email. {% endhint %} *** ### How releases work A typical release follows a simple lifecycle: Release Candidate → Sandbox Testing, where applicable → Release Available | Stage | What to expect | | ----------------- | --------------------------------------------------------------------------- | | Release Candidate | An advance overview of planned functionality and changes is published | | Sandbox Testing | Relevant functionality may be made available in Sandbox for advance testing | | Release Available | Confirmed changes become available as part of the Service | {% hint style="warning" %} Not every release or change requires Sandbox testing or action from you. {% endhint %} *** ### Release Candidate A Release Candidate is normally published at least one month before the planned release date. It provides advance information about changes currently planned for the upcoming release, which may include: * new functionality; * enhancements to existing functionality; * Merchant Portal and UI/UX changes; * payment functionality and payment methods; * API changes; * SDK and plug-in updates; * security, regulatory or payment scheme-related changes; and * changes that may require action from you. #### How you are notified When a Release Candidate is published: * Release Notes are published in the Documentation Portal; * an upcoming release notification is displayed in the Documentation Portal; A Release Candidate represents the planned scope at the time of publication. Individual features, scope or the planned release date may change as the release is finalized. If this happens, the Release Notes and Documentation Portal notification will be updated accordingly. *** ### Sandbox Testing Where relevant functionality is available for testing before the release, this will be clearly identified in the Release Notes. The Release Notes may specify: * what is available for testing; * when it becomes available in Sandbox; * applicable API or component version; * relevant testing considerations; and * whether any action is required before the release date. This gives you the opportunity to validate changes affecting your integration or payment experience before they become part of the Service. {% hint style="info" %} Not all changes require advance Sandbox availability. For example, certain UI/UX improvements, bug fixes, internal technical changes and security updates may not require advance testing. {% endhint %} *** ### Versioning You do not need to track the underlying Service software version. Components that you integrate with or install directly, such as APIs, Mobile SDKs and e-commerce plug-ins, have their own version numbers. #### API API versions follow the format: `vMAJOR.MINOR.PATCH` Example: `v1.0.0` * MAJOR — incompatible changes that may require changes to your existing integration. * MINOR — new functionality or enhancements that remain backwards compatible. * PATCH — backwards-compatible fixes and technical improvements. {% hint style="info" %} A Service release does not automatically result in a new API version. Your integration may continue using the same API version across multiple releases. {% endhint %} #### SDKs and plug-ins Mobile SDKs and e-commerce plug-ins are versioned independently and may have their own release lifecycle. Examples: Mobile SDK `v3.4.1`\ WooCommerce Plug-in `v2.5.0` Where applicable, Release Notes will identify the new component version and whether the update is: * Optional — no upgrade is required; * Recommended — upgrading is recommended to receive the latest functionality, improvements or fixes; or * Required — the component must be upgraded within the communicated timeline. {% hint style="info" %} Where an update is required, the Release Notes will provide or reference the applicable upgrade or migration instructions. {% endhint %} *** ### Release Impact Each relevant change is classified according to its expected impact. | Impact | What it means | What you need to do | | ------------------ | ---------------------------------------------------------------------------------------------- | -------------------------------------------- | | No Action Required | The change is compatible with your existing use of the Service | Nothing | | Awareness Required | The change affects functionality or user experience but does not require an integration change | Review the Release Notes | | Action Required | The change requires an integration, configuration or component update | Follow the instructions in the Release Notes | #### No Action Required Examples may include: * new optional functionality; * Merchant Portal UI/UX improvements; * Hosted Checkout improvements; * backwards-compatible API enhancements; * performance and reliability improvements; and * bug fixes. #### Awareness Required Used when a change affects how you use the Service but does not require technical implementation changes. Examples may include: * significant Merchant Portal changes; * workflow or navigation changes; * reporting enhancements; * new payment functionality; and * changes to existing functionality. #### Action Required Used when you need to make a change to your integration, configuration or installed component. The Release Notes will identify, where applicable: * what is changing; * what you need to do; * affected functionality or component; * Sandbox availability; * migration or implementation instructions; * effective date; and * migration or end-of-support deadline. {% hint style="info" %} Where action is required, review the applicable Release Notes and complete the required changes within the communicated timeline. {% endhint %} *** ### Emergency and security updates Some changes cannot follow the standard release lifecycle. Urgent updates may be required to protect the security, availability, integrity or compliance of the Service or to address urgent regulatory or payment scheme requirements. \ For emergency or security updates, the standard Release Candidate notification period and advance Sandbox availability may not apply. If an urgent update requires action or materially affects the Service, relevant information will be communicated as soon as reasonably practicable. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ecommerce.seb.ee/getting-started/release-notes/release-policy.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.