Laravel Carta Del Docente Laravel Package

Getting Started

v1.3.1 is a compatibility release: the only change is Laravel 13 support. There are no new public APIs, no deprecations, and no breaking changes, so the "getting started" path is identical to v1.3.0 — if you are already on the package, this is a drop-in composer update.

1. Check your constraint first. Confirm composer.json allows the new version (^1.3 or ^1.0 both resolve). If you pinned 1.3.0 exactly, loosen it — otherwise you will not pick up the Laravel 13 compatibility shims.
2. Verify the framework side. Laravel 13 support only matters if illuminate/support, illuminate/contracts, and friends are actually resolvable at 13.x in your project. Run composer why-not laravel/framework 13.* before assuming the package is the blocker.
3. Read the source, not the changelog. With a one-line release note, the fastest orientation is src/ plus the package's service provider. Look for the provider's register()/boot() and anything it merges, publishes, or binds into the container — that is your surface area.
4. Publish and diff config. If the package ships config, run php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" --tag=config and diff against what is already in config/. New Laravel majors often change default driver names or HTTP client behaviour, and a stale published config is the most common cause of "it broke on upgrade" reports.
5. First use case. Take the single smallest thing the package does — one facade call, one trait on a model, one artisan command — and exercise it in php artisan tinker before wiring it into application code. This gives you a baseline you can re-run after the upgrade.

Treat the upgrade as two separate validations: the package works on your current Laravel version (regression check), and it works on Laravel 13 (forward check). Only the second is actually new in this release.

Implementation Patterns

Pin to the patch, not the minor, during the transition. While you migrate a codebase to Laravel 13, constrain the package to ^1.3.1 rather than ^1.0. That keeps you on the release that declares framework-13 support and prevents a future 1.2.x resolution on a fresh CI machine.

Test the matrix, not just the happy path. If the package is a dependency in a library you maintain, add Laravel 13 to your CI matrix as a separate job alongside your current version. A single combined job hides which framework version a failure belongs to.

Isolate the integration behind a thin adapter. Wrap the package's calls in a small application-level class (App\Support\...) rather than scattering facade calls through controllers and jobs. When the next major Laravel release forces a package bump, you change one file instead of grepping the codebase. This pays off disproportionately for packages that ship a facade plus a config array.

Feature-detect framework behaviour, not versions. If your code branches on framework behaviour that changed in Laravel 13, prefer capability checks (method_exists, Container::getInstance()->bound(...)) over version_compare(app()->version(), '13.0', '>='). Version sniffing rots badly across patch releases.

Upgrade in a branch with the lockfile committed. Because this release is compatibility-only, the diff should be composer.json (constraint) plus composer.lock and nothing else. If you see application-code changes in that diff, something else moved and you should investigate before merging.

Order your dependency bumps. Laravel 13 support in this package does not mean your other packages support Laravel 13. Bump the framework first, let composer update --with-all-dependencies tell you what fails, and treat this package as one item in that queue rather than the trigger.

Gotchas and Tips

• "Laravel 13 support" is a claim, not a contract. A one-line note usually means the composer.json constraint was widened and the suite was run against 13. It does not guarantee every code path was exercised. Skim the test suite for framework-version conditionals and check whether CI actually runs 13 or just permits it.
• Widened constraints can mask real breaks. The most common failure mode in a release like this is a transitive dependency that still caps at 12, producing a composer conflict that looks like the package's fault. Run composer update --dry-run and read the solver output before assuming an incompatibility.
• Laravel 13 skeleton drift, not package drift. If things break after upgrading, the cause is usually the application skeleton (middleware aliases, bootstrap/app.php structure, provider registration) rather than the package. Bisect by testing the package against a fresh Laravel 13 app before debugging your own.
• Clear compiled state after the bump. php artisan config:clear && php artisan cache:clear && php artisan optimize:clear, then re-run. Cached config from a previous framework version is a silent source of confusing errors.
• Watch deprecation output even though none are announced. Run the suite with deprecations surfaced (PHPUnit's --display-deprecations, or set error_reporting(E_ALL) in a dev harness). Framework majors routinely trigger notices inside packages that do not appear in the changelog.
• Extension points to audit for upgrade risk. Service provider bindings and singletons, published config keys, facade accessors, and any class the package expects you to extend. These are the seams where a framework major leaks through, and they are what you will need to patch locally if something slips through QA.
• Pin CI images too. A green local run with a stale vendor/ tells you nothing. Rebuild from a clean composer install on the matrix job you added, or you will ship a false positive.
• Record the compatibility boundary. Note in your project README/changelog that the package is validated on Laravel 13 only from v1.3.1 onward. Future you — or the next developer — will otherwise re-derive this from git history.