VAVANG Invoice RC
FR EN
VAVANG INVOICE / DOCS / EN

Versioning and backward compatibility

Vavang Invoice follows Semantic Versioning for published commercial releases, with an explicit release-note contract for every version.

Version numbers

For stable releases (MAJOR.MINOR.PATCH):

  • PATCH: backward-compatible bug, security, compatibility or regulatory fixes;
  • MINOR: backward-compatible features and extensions;
  • MAJOR: changes that intentionally break the supported public contract.

The plugin is still prepared on a pre-1.0 development line (dev-main currently aliases 0.1.x-dev). Pre-1.0 does not remove the obligation to document breaking changes: every beta/RC/release candidate must still state them explicitly.

What is part of the compatibility contract

Backward compatibility covers the documented integration surface, including:

  • supported PHP/Sylius/Sylius InvoicingPlugin ranges;
  • public plugin configuration keys and documented values;
  • documented service interfaces and extension points;
  • documented commands and operational procedures;
  • persisted database schema and migration path;
  • documented events/hooks relied on by integrators;
  • compliance-history and transmission-history invariants.

Internal implementation details that are not documented as extension points are not a public BC promise.

Deprecation policy

When practical, a public contract that must be removed or renamed is deprecated before removal. The deprecation must identify the replacement and the target removal window in release notes/documentation.

An immediate breaking change can still be required by a security issue, regulatory requirement or upstream/provider incompatibility. In that case the release must explicitly mark the breaking change, manual action and migration/rollback implications; it must never be shipped as an undocumented patch.

Database compatibility

A migration is not assumed rolling-safe merely because Doctrine can execute it. Every release declares one of:

  • rolling-compatible — schema changes remain compatible with the previous application version during rollout;
  • maintenance required — the release contains an operation that cannot safely coexist with the previous version.

The release-specific declaration in the changelog controls deployment behavior.

Pre-release rule

Beta/RC versions can evolve faster than stable releases, but breaking changes, configuration changes, migrations and operator actions remain explicit. A release candidate promoted to stable must have a complete changelog entry and green release/clean-install gates.