Maintaining Extras

Maintenance Is More Than Code

An extra becomes hard to trust when people can install it but cannot understand its config, commands, migrations, or upgrade impact. Good maintenance is code plus documentation.

Minimum Package Documentation

• supported Evolution and PHP versions
• Composer package name
• install commands
• migration behavior
• published config file and important settings
• available Artisan commands
• included views, assets, and manager modules
• upgrade notes and breaking changes

What example-package Documents Well

• package name and requirements in composer.json
• quick install flow in README.md
• package config in config/example.php
• demo command in example:install-demo
• what templates, TVs, and demo resources the seeder creates
• how frontend assets are rebuilt or published
• how to disable demo behavior in production

Compatibility Checklist

• verify the package against the target Evo minor version
• check PHP compatibility explicitly
• confirm that migrations are safe to rerun or document when they are not
• check whether seeded TVs, aliases, or templates may collide with existing projects
• note whether classic assets are namespaced or not

Upgrade Rule

Every extra that changes routes, migrations, config shape, templates, or element names should ship upgrade notes. Do not expect users to diff the package source manually.

For the creation flow, see Creating an Extra. For install paths, see Installing Extras.