define package conflicts

[schuer]

fixes #51

[staabm]

//cc @gharlan

[gharlan]

👍

Nur noch mal zur Klarstellung: Folge ist, sobald irgendeines der Addons in Version 3 erscheint, können die Leute, die Cache Warmup installiert haben, das jeweilige Addon nicht updaten.
Die müssen dann entweder Cache Warmup deinstallieren, oder updaten (falls schon neue Version da, die auch die Version 3 unterstützt), oder halt das andere Addon nicht updaten.

Kann also auch nerven, vor allem, wenn Cache Warmup eigentlich doch mit der Version 3 kompatibel wäre.

Aber da wir das ja jetzt nicht wissen können, finde ich das alles so richtig. Wie Markus ja sagte, offene Grenzen nach oben sind ein Antipattern.
Und ich denke so ist es auch besser, als wenn man dann zwar updaten darf, aber dann plötzlich komische Dinge passieren (bzw. nichts mehr passiert).

[staabm]

Vllt solltest du hier nen kommentar reinmachen was diese regel bewirkt... conflict rules sind bisher in FOR nicht üblich

[schuer]

Done, danke.

[staabm]

@gharlan haben wir eine ordentliche message beim installieren wenn es wg einem conflikt nicht klappt? (Damit die leute wissen was das problem ist und die ursache erkennen kann)?

[gharlan]

Dies sind die Meldungen, die auftreten können, je nach Konstellation:
https://github.com/redaxo/redaxo/blob/master/redaxo/src/core/lang/de_de.lang#L284-L291

Da drüber steht dann noch sowas wie "Addon X konnte aus folgendem Grund nicht aktualisiert werden:".
Im oben genannten Fall, also jemand versucht eines der anderen Addons auf Version 3 zu aktualisieren, würden die _reverse_conflict_-Messages greifen.

[staabm]

@gharlan brauchts auch ne conflict rule für php >7 (da wir hier noch kein || können?)

[gharlan]

Bei der PHP-Version scheint es üblicher zu sein, die Grenze doch nach oben offen zu lassen. Zumindest sehe ich das meist so in den composer.json's.
Ein Beispiel, Symfony: https://github.com/symfony/symfony/blob/master/composer.json#L19

[schuer]

Danke euch! Wollen wir dann mergen?