Verified against Semitexa Ultimate 2026.10.29.1052

Versions and stability

After this page you can tell which parts of Semitexa your code may rely on from one release to the next, and how much warning you get before one of them goes away.

Prerequisites: none. To try the commands, a project installed as in Installation.

What a version number says

Every release is tagged with the UTC date and time it was cut: 2026.10.29.1052 is 29 October 2026, 10:52 UTC. Tags are placed on master. A release tags each package that changed since its last tag; a package that did not change keeps the version it had.

The number is a date, not a compatibility signal. A later date is a newer release; nothing in the digits says whether it breaks anything. What it does say is when, and the promise below is made in time: a deprecated part keeps working for a stated number of days, counted from dates you can read straight off the version.

semitexa/ultimate pins every semitexa/* package to the exact version it was tested with, so a project moves the whole framework at once:

bin/semitexa update --dry-run
bin/semitexa update:changelog

The first shows which packages move and to which version; the second, after an update, what changed.

What is promised: @api

The promise covers what is marked @api in its docblock, and nothing else. Marking is deliberate and opt-in: a class, interface, trait, enum or method is public API when the framework has said so, not because PHP lets you call it.

For example:

/**
 * @api
 */
interface Clock
{
    public function now(): \DateTimeImmutable;
}

For a symbol marked @api, a release does not, without the deprecation below:

  • remove it, or rename it;
  • remove a public method, a constant, an enum case, or a parameter;
  • add a required parameter, or change a parameter's or a return value's type to one your existing code no longer fits;
  • add a method to an interface or an abstract method to a class you are meant to implement or extend.

A class marked @api makes that promise for its public methods; a single method can also be marked on a class that is not.

What these are is said in the code, so you can list them in your own vendor/:

grep -rln '@api' vendor/semitexa/*/src

Packages are being marked one at a time, starting with semitexa/core: the contracts you implement, the attributes you write on your own classes, and the base classes you extend. A package in which that command finds nothing has made no promise yet.

What is not promised

Everything not marked @api can change in any release: unmarked classes and methods, anything marked @internal, the shape of generated files and caches, and the text of console output and log messages. Code that relies on them works today and may need a change after an update; update --dry-run and update:changelog are where you see that coming.

Deprecation: 90 days

When a part of the @api surface has to change, the old form is deprecated first and keeps working:

/**
 * @api
 * @deprecated 2026.11.02 Use Clock::now() instead.
 */
public function currentTime(): \DateTimeImmutable
  • @deprecated gives the date it was deprecated — YYYY.MM.DD, or the version of the release that shipped it — and what to use instead. phpstan's semitexa.deprecatedApi rule refuses one without either.
  • The deprecated part keeps working, unchanged, for at least 90 days after the first release that carries the deprecation, which is dated that day or later.
  • It may be removed in the first release cut after those 90 days, not before. With the example above, first shipped in a release on 2 November 2026, that is a release on or after 31 January 2027.

So a project that updates at least every 90 days always sees a deprecation, and its replacement, before the removal reaches it.

Fixes for older releases

Only the latest release is supported. There are no maintenance branches and no long-term-support line: a fix, including a security fix, ships in the next release, and updating is how you get it. The 90-day window above is what makes updating often safe for code that stays on the @api surface. How to report a vulnerability is in each package's SECURITY.md.

Next steps

  • Upgrading — what bin/semitexa update does, step by step
  • Installation — a project to try the commands in
Have a product idea?One free MVP every month