vienthuong
commented
10 months ago Hi @SpiGAndromeda That's a good branching strategy, I'm planning to have a major update with the news PHP compatibility to fit with shopware's constraint and also the news version for SW 6.6, I will consider your suggestion if it's feasible but having different versions for each minor SW version makes them even more confusing and takes effort whenever a new minor version. I'd probably create a new major version (3.0.0) for this plugin (6.5.x only) and when the 6.6 release, I'd create 6.6-1.0.0 that's compatible with 6.6 upward.
htuscher
Since, PHP 8.2 a lot of deprecation warning are thrown because the entity properties doesn't always match the transmitted data from Shopware.
Because this package should be compatible with PHP versions below 8.2, the
AllowDynamicPropertiesattribute (https://www.php.net/manual/en/class.allowdynamicproperties.php) cannot be used.Updating the entities with the current versioning strategy makes also no sense, because it would only reflect the entity properties of one Shopware version. So all other versions that should be compatible would throw warnings or errors.
I would suggest to move away from simple versioning like 1.7.3 or 2.0.0 to a versioning like 6.5.6-2.0.0, 6.5.7-2.0.0. The versions could be exactly the same but don't have to be. The idea is that one would fix the own project to a specific Shopware version but allows updates of this package that are not tied to a Shopware version.
To manage the Shopware versions, a "master"/"main" branch per Shopware version would be required. Any changes that are not tied to a specific Shopware version, could be merged into every one of these branches. The branches would have a slightly different base (e.g. some more or less entity properties).
To make the creation of the Shopware version specific branches/changes easier, they could be "copied" from the Shopware Core repository. I don't know how this could be done efficiently, yet ... but I am sure that could be figured out.
best regards, spigandromeda