Changelog

Guppy und alle Guppy-Plugins folgen strikt Semantic Versioning. Diese Seite beschreibt die Versionierungs-Regeln, den Update-Workflow und wo du die offiziellen Release-Notes findest.

SemVer-Schema

MAJOR.MINOR.PATCH

MAJOR: Breaking Changes

Inkompatible Änderungen, die manuelle Anpassungen erfordern:

• Template-Blöcke entfernt oder umbenannt
• Konfigurationsoptionen entfernt
• CSS-Klassen fundamental geändert
• JavaScript-Plugin-APIs geändert

Beispiel: 2.6.1 → 3.0.0 (MINOR und PATCH werden auf 0 zurückgesetzt).

MINOR: Neue Features

Rückwärts-kompatible Funktionalitäten:

• Neue Template-Blöcke oder Properties
• Neue Konfigurationsoptionen
• Zusätzliche CSS-Klassen
• Neue JavaScript-Plugin-Features

Beispiel: 2.1.3 → 2.2.0 (PATCH wird auf 0 zurückgesetzt).

PATCH: Bugfixes

Rückwärts-kompatible Fehlerbehebungen:

• Styling-Korrekturen
• Performance-Optimierungen
• Nicht-funktionale Verbesserungen

Beispiel: 2.1.1 → 2.1.2.

Release-Notes pro Plugin

Da Guppy aus mehreren Plugins besteht, leben die offiziellen Release-Notes je Plugin im jeweiligen GitLab-Repository unter Releases. Mehrere Plugins bringen zusätzlich ein englisches CHANGELOG.md mit.

Plugin	Changelog-Quellen
DmfGuppyTheme	GitLab-Tags, CHANGELOG.md
DmfAutoStyleguide	CHANGELOG.md
DmfSplideSlider	CHANGELOG.md
Übrige Plugins	GitLab-Tags + Plugin-composer.json version

Shopware-Update-Workflow

1. Shopware UPGRADE.md analysieren

Shopware liefert pro Release eine UPGRADE.md mit Breaking Changes:

curl -s https://raw.githubusercontent.com/shopware/platform/trunk/UPGRADE.md

2. Automatisierte Kompatibilitätsprüfung

DmfGuppyTheme bringt einen Scanner mit:

# alle installierten Komponenten prüfen
bin/console guppy:upgrade:scan

# gegen eine Ziel-Shopware-Version
bin/console guppy:upgrade:scan --shopware-version=6.7.0

# Bericht in Datei
bin/console guppy:upgrade:scan --format=json --output-file=upgrade-report.json

Option	Beschreibung
--shopware-version	Ziel-Shopware-Version (z. B. 6.7.0)
--target-version	Ziel-Guppy-Version
--format	table, json, yaml
--output-file	Bericht in Datei schreiben
--verbose	detaillierte Debug-Ausgabe

3. Update durchführen

composer update dmf/sw6-guppy-theme
bin/console plugin:refresh
bin/console plugin:update DmfGuppyTheme
bin/console theme:compile
bin/console cache:clear

theme:compile pflicht

Nach Plugin-Update muss theme:compile laufen, sonst werden weder neue SCSS-Werte noch Twig-Änderungen wirksam.

Branching-Strategie als Update-Quelle

Branch / Tag	Wann verwenden
getaggte Version (z. B. v2.6.0)	Produktion
RC-Tag (z. B. v2.8.0-rc1)	Testen kommender Shopware-Major-Versionen
main	bewusst „neueste stabile Version” ohne Tag, selten in Produktion
stage	nur Test-Umgebungen

Details: Mitwirken.

CI-Integration

Beispiel .gitlab-ci.yml-Step für wöchentlichen Upgrade-Check:

upgrade-check:
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
  script:
    - composer install
    - bin/console guppy:upgrade:scan --format=json --output-file=upgrade-report.json
  artifacts:
    paths:
      - upgrade-report.json

Hotfixes

Außerhalb der regulären Releases werden kritische Bugfixes als PATCH veröffentlicht. Details zum Workflow: Mitwirken → Hotfixes.

Verwandt

• Mitwirken: Branch-Strategie und Workflow.
• Architektur: guppy:upgrade:scan und weitere Console-Commands.