Support
HelpDoku für Befüller:innen
  1. Development
  2. Laravel
  3. Packages Entwicklung

    Release- & Update-Workflow

    Wie man eine neue Version dieses Theme-Packages veröffentlicht (Tag anlegen & pushen) und wie die konsumierenden Services das Update einspielen.

    Verteilung läuft über Composer + Git-Tags (VCS-Repository), nicht über Packagist.
    Versionsschema: Semantic Versioning – `MAJOR.MINOR.PATCH`.

    1. Wann welche Versionsnummer?

    ÄnderungBeispielVersion-BumpNeuer Tag
    Patch
    Bugfix, keine API-Änderung    		Tippfehler im CSS, falscher Hex-Wert1.0.0 → 1.0.1v1.0.1
    Minor
    neues Feature, abwärtskompatibel    		neue Config-Option, zusätzliche Farbe1.0.1 → 1.1.0v1.1.0
    Major
    Breaking Change
    		Trait umbenannt, Config-Key entfernt1.1.0 → 2.0.0v2.0.0

    Faustregel: Solange Services mit ^1.0 requiren, dürfen Patch- und Minor-Releases sie nie kaputt machen. Alles, was bestehende Services bricht, ist ein Major.

    2. Release veröffentlichen

    Apache Config
    # Änderungen comitten add -A git commit -m "kurze Beschreibung der Änderung" # 2. Annotierten Tag anlegen (NICHT lightweight – annotiert trägt Autor/Datum/Message) git tag -a v1.1.0 -m "v1.1.0 – kurze Release-Beschreibung" # 3. Branch UND Tag pushen (zwei getrennte Pushes!) git push origin main git push origin v1.1.0

    Prüfen, dass der Tag auf dem Server liegt:

    Apache Config
    git ls-remote --tags origin

    3. Was dabei passiert

    • Lokal ordnet der annotierte Tag einem bestimmten Commit einen unveränderlichen Versionsnamen zu (inkl. Tagger, Datum, Message – als eigenes Git-Objekt).
    • Beim Push landet der Tag im Gitea-Repo (`app1.bakehouse.at:10022/cookis/...`).
    • Composer liest beim Auflösen die Git-Tags des VCS-Repos und mappt sie auf Package-Versionen: Tag v1.1.0 → Composer-Version 1.1.0.
    • Ein Service mit "cookis/laravel-filament-theme": "^1.0" bekommt beim nächsten composer update automatisch die höchste passende 1.x-Version (also 1.1.0), aber nicht 2.0.0.

    4. Gegenseite updaten (konsumierende Services)

    Apache Config
    composer update cookis/laravel-filament-theme

    Das holt die neue Version (im Rahmen des ^-Constraints) und schreibt sie in die
    composer.lock. Danach – falls der Service Config-Caching nutzt:

    Apache Config
    php artisan config:clear # oder: php artisan config:cache (Produktion)

    SELTEN!!!! Bei reinen Theme-/CSS-Änderungen ist meist kein weiterer Schritt nötig (buildless). Wurde die Config-Struktur geändert und der Service hat sie gepublished, ggf. php artisan vendor:publish --tag=filament-theme-config --force neu ausführen.

    Major-Update (z. B. v2.0.0)

    Bei einem Breaking Change muss der Service den Constraint bewusst anheben:

    JSON
    // composer.json "require": { "cookis/laravel-filament-theme": "^2.0" // vorher: "^1.0" }
    Apache Config
    composer update cookis/laravel-filament-theme

    Erst danach (und nach Anpassung an die Breaking Changes) zieht der Service 2.x.