Talaria
Docs

PHP upgrade

Upgrade talaria/talaria, talaria/silverstripe, and talaria/laravel with Composer. Commit the lock file, install it on deploy, and apply each version's config changes.

talaria/talariaupgradecomposersilverstripelaravel

talaria/talaria 2.0.0 is the current core. talaria/silverstripe 2.0.1 and talaria/laravel 2.0.1 require that core (^2.0.0). PHP 8.1 or newer.

Upgrade the package your app requires and the core it depends on in one Composer command. A Silverstripe site follows Upgrade the Silverstripe module for the flush and the module's config. This page is the shared Composer procedure and the core version changes.

See the installed version

From the application root (the directory that contains composer.json and composer.lock):

bash
composer show talaria/talaria
composer outdated --direct "talaria/*"

Run composer show the same way for talaria/silverstripe or talaria/laravel when that package is installed. composer show prints the locked version. composer outdated prints the newest version your constraints allow. If a package name is not in the lock file, Composer says it is not found — that app does not use it.

When the solver refuses a version, ask why:

bash
composer why-not talaria/talaria 2.0.0

Update the unit you installed

App Already allows the target (same major, or an open ^1.0) Crossing into 2.0 when the constraint is still ^1.2
Plain PHP composer update talaria/talaria -W composer require talaria/talaria:^2.0 -W
Silverstripe composer update talaria/silverstripe talaria/talaria -W composer require talaria/silverstripe:^2.0 talaria/talaria:^2.0 -W
Laravel composer update talaria/laravel talaria/talaria -W composer require talaria/laravel:^2.0 talaria/talaria:^2.0 -W

composer update installs the newest release that the constraint already in composer.json allows. ^1.2 means >=1.2.0 <2.0.0, so update stays on 1.x. composer require vendor/package:^2.0 changes that constraint and updates the lock file in one step.

-W is --with-all-dependencies. Composer may update dependencies of those packages, including packages your root composer.json also requires. A newer adapter that needs a newer core fails to resolve without it. Use the same -W on composer require when you cross a major.

Preview the solve before writing the lock file:

bash
composer update talaria/silverstripe talaria/talaria -W --dry-run

Use the package names for the app you have. Read the dry-run. Then run the same command without --dry-run.

Read git diff composer.lock before you commit. -W can move other libraries those packages depend on. talaria/silverstripe allows Silverstripe 4.13, 5, and 6, so a wide silverstripe/framework constraint can change the CMS major in the same solve. Keep the framework on the major you are already running. If the diff moves it, set an explicit framework constraint in the app and run the Talaria update again.

Do not run a bare composer update with no package names. That upgrades every dependency in the lock file.

Test, then commit the lock file

Exercise the path that reports to Talaria: a request, a logged error, and a CLI or queue job if you use one. Silverstripe's build and flush are on the Silverstripe upgrade page. Laravel: php artisan config:clear, and restart Octane if the app uses it.

Commit both files. The lock file is the version you tested.

bash
git add composer.json composer.lock
git commit -m "Upgrade Talaria dependencies"

composer.json changes when a constraint moves (for example ^1.2 to ^2.0). composer.lock changes on every resolved update. UAT and production install that lock file. They do not resolve versions again.

Deploy with install, not update

bash
composer install --no-dev --optimize-autoloader

composer install reproduces the lock file. composer update on the server resolves versions again and can ship a set you did not test.

Restart PHP after the new code is on disk so OPcache loads it. A rejected API key is cached for about 24 hours in that process. Restarting is also how a rotated key is picked up.

1.x to 2.0.0

2.0.0 removes the environment init option. The API key decides the environment. Events, spans, and analytics no longer send an environment string.

  • Delete environment from Talaria::init([...]).
  • Delete TALARIA_ENVIRONMENT from the environment.
  • On Silverstripe, delete the environment key under Talaria\SilverStripe\Config. Details are on the Silverstripe upgrade page.
  • On Laravel, delete the environment key from a published config/talaria.php and run php artisan config:clear. APP_ENV is not a substitute.

An event that used to be labelled by that string now shows up under the key's environment (development, test, staging, or production). Use a development key locally and a production key on the deployed app. The prefix stays tal_live_.

talaria/silverstripe 2.0.0 and talaria/laravel 2.0.0 require talaria/talaria ^2.0.0. A 1.x adapter does not install against 2.0.0 core, and a 2.0 adapter does not install against 1.x core. Upgrade the pair together.

1.1 to 1.2.0

1.2.0 reads tracing, analytics, and the event sample rate from POST /sdk/getConfig. These init options no longer change that behaviour:

  • enableTracing
  • tracesSampleRate
  • enableAnalytics
  • sampleRate

Until a config document is cached, the process sends errors only. Turn tracing and analytics on in Project settings. A rejected key stops the process until PHP restarts.

Silverstripe YAML and TALARIA_ENABLE_TRACING / TALARIA_ENABLE_ANALYTICS are passed into init and then discarded by 1.2.0 core. The dashboard switches are the ones that apply.

Inside 1.2 and 2.0

Stay on the newest 2.0.x. These 1.2 patch releases still matter if you are stepping through 1.x before the major:

Version What changes for the running app
1.2.2 Each uncaught exception is one event. The engine's "Uncaught … thrown" shutdown line is not sent again.
1.2.3 Identical SQL under one parent is one span with db.query.count and db.query.duration_sum_ms. Queries of 200ms or more, and failed queries, stay their own spans. A transaction keeps at most 200 spans. withoutQuerySpans turns automatic SQL spans off for one run.
1.2.4 Talaria::flags() (boolVariation, stringVariation, jsonVariation). Flag state follows flags.enabled in the project config.
2.0.1 adapters Silverstripe and Laravel pin @newtalaria/browser 0.5.3. Core stays 2.0.0.