VAVANG Invoice RC
FR EN
VAVANG INVOICE / DOCS / EN

Maintenance and update policy

An active Vavang Invoice subscription includes corrective, compatibility and regulatory updates published during the entitlement period for supported versions.

What maintenance includes

Published maintenance can include:

  • bug and regression fixes;
  • security fixes;
  • compatibility changes for versions explicitly added to the supported matrix;
  • regulatory/compliance corrections in behavior implemented by the plugin;
  • provider connector maintenance for capabilities explicitly supported by the release;
  • migrations and upgrade instructions required by those changes.

Maintenance does not guarantee indefinite support for end-of-life PHP, Symfony, Sylius or provider APIs.

Release compatibility

Every release must declare its supported matrix and migration compatibility. A package constraint is not widened until the new combination is covered by CI/clean-install validation.

Breaking changes follow the versioning/changelog policy and must never be hidden inside a routine maintenance release.

Subscription period

The standard entitlement lasts 12 months from purchase/renewal. Renewal extends update and support entitlement for another 12 months and keeps existing licensed production bindings.

After expiry:

  • the installed version lawfully obtained while active may continue to run;
  • access to newly published commercial versions and standard support is unavailable until renewal;
  • new production installation bindings are unavailable under the standard policy until renewal;
  • existing fiscal processing and history remain operational.

Update responsibility

Vavang publishes the package, migrations, compatibility information and upgrade procedure. The merchant/integrator remains responsible for planning and applying releases in the host application, including backups, deployment gates, worker restarts and project-specific regression tests.

A regulatory update can be operationally important, but it must still be deployed and validated; an active subscription does not remotely mutate the merchant application.

End-of-life changes

When a supported runtime/provider line must be dropped, the release documentation must state the compatibility change. Where practical, deprecation/migration guidance is published before removal. Security, regulatory or upstream-provider constraints can require a faster change and will be documented explicitly.