标签：#deprecation

When PHPStan reports that your extension calls a deprecated method, the expected next step is quite clear: find the replacement and migrate your code. But what if there is no replacement? Consider Context::scope() . Previously, its planned change for Shopware 6.8 was announced like this: /** * @deprecated tag:v6.8.0 - reason:new-optional-parameter - parameter $states will be added */ public function scope ( string $scope , \Closure $callback ) : mixed Static analysis sees @deprecated and reports every call to the method. However, the method is not going away. A new optional parameter will be added, so existing calls will continue to work without any changes. There is no alternative API to migrate to and no warning to resolve. In this situation, @deprecated is effectively crying wolf. With Shopware 6.7.14.0, we are changing how these planned API changes are communicated. Real deprecations remain deprecations. Other backward-compatibility changes are now described with dedicated, structured PHP attributes. The immediate result is less noise for extension developers. Additionally, the new attributes give us a foundation for preparing extensions for Shopware 6.8 - and future major releases - before those releases arrive. TL;DR Shopware now uses two different signals for two different purposes: @deprecated means that an API is obsolete and will be removed or replaced. Extension developers need to migrate away from it. BC-change attributes describe a future change to an API that remains available, such as a new parameter, a narrower return type, or a class becoming final. The attributes also distinguish between changes that affect code calling an API and changes that affect classes extending it. This means deprecation warnings become trustworthy and actionable again, while planned contract changes carry enough structured information for PHPStan, Rector, IDEs, and other tools to reason about them. We were asking @deprecated to do two different jobs The commonly understood