Contact Center Product Release Lifecycle & Support Periods

overview this page outlines key dates and policies for the lifecycle support of ameyo platform product releases (versions 2 x, 3 x, 4 x) understanding these milestones helps customers plan upgrades and maintain secure, well supported environments key support milestones general availability (ga) date when first ga release for a product is announced end of life (eol) date when product’s active development stops and eos is announced end of sale (eos) end of sale, last date to purchase fresh licenses end of maintenance (eom) end of scheduled maintenance for functional and security issues last day of support (ldos) last day of support, end of support for any identified or unidentified functional or security issue historical version milestones product version ga eol eos eom ldos r2 x 1 aug 2013 1 may 2015 1 nov 2015 1 may 2017 1 nov 2018 r3 x 1 mar 2015 1 may 2017 1 nov 2017 1 may 2019 1 nov 2020 r4 x 1 may 2017 tba eol + 6mo eol + 24mo eol + 36mo latest release latest release major 4 minor 4 13 patch 4 13 40 support period | recent release minor version ga supported till 4 13 apr’2022 tba 4 12 mar’2021 apr’2023 4 11 dec’2020 mar’2022 4 81 sep’2020 dec’2021 release type policies major release it contain following updates significant architectural upgrades, new software components product interfaces (ui, api, events) for integration/customisation software version upgrades (java, db, redis, react etc ) any feature requests which requires 6 months or more of time customer issues (if applicable) tech debts (largely the architecture gaps and innovation) after eol is declared for a major version, bug fixes, security fixes will be made available till “eol + 24 months” and support would be stopped after “eol + 36 months” while migrating across major versions, the changes in product architecture / interfaces may necessitate customisations, integrations to be re done minor release it contain following updates product feature requests, tech debts regulatory compliance (rbi, trai mandates etc ) customer, qa reported issues (if applicable) minor versions shall go out of support 12 months after the release of the next minor version customers shall be able to upgrade from a minor version (release n) or a patch release of that minor version to the next minor version (release n+1) for e g upgrading from 4 12 to 4 13 or from 4 12 x to 4 13 will work seamlessly if a customer wants to move to an older minor version from the current minor version \[rollback], in exceptional cases, db restore is the only option patch releases it contain following updates customer, qa reported issues, small features requests regulatory compliance (rbi, trai mandates etc ) shall mostly be binary updates for ease of upgrades configuration changes, db schema changes patch releases shall not require any db migrations patch releases support will have the same sla as the parent minor version db version upgrades, os version upgrades etc shall not be done as part of patch releases hotfixes are always released on the latest patch of a supported minor version only where the issue is reported (e g , issues found in 4 13 x are resolved in the latest 4 13 patch)