Releases and Support Policy
This page answers how long a version is supported. Its sibling, Support, answers how fast we respond. They are different promises and worth keeping apart.
Versioning
All three packages follow Semantic Versioning. A patch fixes, a minor adds, a major breaks — and nothing breaks in a patch or a minor. The current major of each package is on the home page.
The window
One window, applied identically to laravelui5/odata, laravelui5/core and laravelui5/sdk. It has to be identical, because the packages stack: the SDK requires Core, and Core requires OData. A layer cannot be supported longer than the layer beneath it.
| Current major | Previous major | |
|---|---|---|
| Security fixes | yes | yes, for 12 months after its successor is released |
| Bug fixes | yes | no |
| New features | yes | no |
| Compatibility with a new Laravel major | yes | no |
And one hard limit, which is not ours to set
A major is supported only while at least one Laravel version it runs on is still receiving security fixes from Laravel.
We build on Laravel. Patching our code on top of an unpatched framework would be a promise we cannot honour, so the window ends there even if the twelve months have not run out.
This also means the limit is externally verifiable: Laravel publishes its own dates, and you can check ours against them without asking us. Laravel gives every major 18 months of bug fixes and 24 months of security fixes (Laravel support policy).
A major can gain time. If we widen a major's Laravel constraint in a minor release — say from ^12 to ^12 || ^13 — its window moves with the newer Laravel. That is a deliberate act on our side, announced in the changelog, not something that happens quietly.
What the four rows mean
Most support disputes are about vocabulary rather than duration, so here is ours.
Security fixes — a change that closes a vulnerability in the package as distributed. Delivered as a patch release on the affected major. This is the only category the previous major receives.
Bug fixes — a change that makes the package do what it is documented to do. If the behaviour and the documentation disagree, the documentation describes the target and the code moves to meet it.
New features — anything additive: new artifacts, new attributes, new commands, new options. These land in minor releases on the current major only, and are never backported.
Compatibility with a new Laravel major — the work of making a package run on a Laravel version it did not support when it shipped. This is the expensive one, and it is the one most often assumed to be included. It is not, for a previous major. If you need your current LaravelUi5 major to run on a newer Laravel, that is either a reason to upgrade or a case for extended maintenance below.
What differs per package
The window is the same. What differs is who is entitled to it.
| Package | Licence | Entitlement |
|---|---|---|
laravelui5/odata | MIT | everyone |
laravelui5/core | Business Source License 1.1 | everyone with a free account |
laravelui5/sdk | commercial | while your licence is active |
One note on Core, because it is easy to read the wrong way
Each Core release converts to Apache 2.0 four years after it ships. That is a licence promise, not a support promise. Four years after release you may do anything Apache 2.0 permits with that code — but it has not been supported for most of that time, and nobody is patching it. The two dates are unrelated and should not be read together.
Extended maintenance
When the standard window ends and you cannot upgrade yet, security fixes for one named major can be continued under a paid extended-maintenance agreement.
- What it covers: security fixes on that major, delivered as patch releases, for a fixed term.
- What it does not cover: bug fixes, new features, or compatibility with a newer Laravel major.
- What it cannot do: outlive Laravel's own security support for a version that major runs on. If the framework beneath is unpatched, we cannot make the package safe, and we will say so rather than sell you the agreement.
- Availability:
laravelui5/sdk. Ask at[email protected].
If upgrading is the real problem
Sometimes the honest answer is not to extend the old major but to move off it. We do major upgrades as a project — scoped, fixed, with the upgrade itself as the deliverable. If the reason you are asking about extended maintenance is that nobody has time for the upgrade, say so and we will quote that instead. It is usually cheaper and it ends the problem rather than postponing it.
Response times are a separate thing
Nothing on this page is a service-level agreement. Version lifetime says which releases still get fixes; it says nothing about how quickly we answer. Our response targets, and the terms under which they become guarantees, are on the Support page.