From 0de00003c69dbb1671f80cecee9779cd0870ed2e Mon Sep 17 00:00:00 2001 From: Art4 Date: Mon, 13 Jan 2025 22:38:07 +0000 Subject: [PATCH 1/6] add Backward Compatibility Promise --- doc/Developers-Intro.md | 73 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) diff --git a/doc/Developers-Intro.md b/doc/Developers-Intro.md index c500b27741..e37313c73f 100644 --- a/doc/Developers-Intro.md +++ b/doc/Developers-Intro.md @@ -156,3 +156,76 @@ If you are interested in improving those clients, please contact the developers * iOS: *currently no client* * SailfishOS: **Friendiy** [src](https://kirgroup.com/projects/fabrixxm/harbour-friendly) - developed by [Fabio](https://kirgroup.com/profile/fabrixxm/profile) * Windows: **Friendica Mobile** for Windows versions [before 8.1](http://windowsphone.com/s?appid=e3257730-c9cf-4935-9620-5261e3505c67) and [Windows 10](https://www.microsoft.com/store/apps/9nblggh0fhmn) - developed by [Gerhard Seeber](http://mozartweg.dyndns.org/friendica/profile/gerhard/profile) + +## Backward compatability + +### Backward Compatibility Promise + +Friendica can be extended by addons. These addons relies on many internal classes and conventions. As developers our work on Friendica should not break things in the addons without giving the addon maintainers a chance to fix their addons. Our goal is to build trust for the addon maintainers but also allow Friendica developers to move on. This is called the Backward Compatibility Promise. + +We promise BC inside every major release. If one release breaks BC, this should considered as a bug and will be fix in a bugfix release. + +Inspired by the [Symonfy BC promise](https://symfony.com/doc/current/contributing/code/bc.html) we promise BC for every class, interface, trait, enum, function, constant, etc., but with the exception of: + +- Classes, interfaces, traits, enums, functions, methods, properties and constants marked as `@internal` or `@private` +- Extending or modifying a `final` class or method in any way +- Calling `private` methods (via Reflection) +- Accessing `private` propertyies (via Reflection) +- Accessing `private` methods (via Reflection) +- Accessing `private` constants (via Reflection) +- New properties on overrided `protected` methods +- Possible name collisions with new methods in an extended class (addon developers should prefix their custom methods in the extending classes in an appropriate way) +- Dropping support for every PHP version that has reached end of life + +Breaking changes will be happen only in a new release but MUST be hard deprecated first. + +### Deprecation and removing features + +As the development goes by Friendica needs to get rid of old code and concepts. This will be done in 3 steps to give addon maintainer a chance to adjust their addons. + +**1. Label deprecation** + +If we as the Friendica maintainers decide to remove some functions, classes, interface, etc. we start this by adding a `@deprecated` PHPDoc note on the code. For instance the class `Friendica\Core\Logger` should be removed, so we add the following note with a possible replacement. + +```php +/** + * Logger functions + * + * @deprecated 2025.02 Use constructor injection or `DI::logger()` instead + */ +class Logger {/* ... */} +``` + +This way addons developers might be notified by their IDE or other tools that the usage of the class is deprecated. In Friendica we can now start to replace all occurences and usage of this class with the alternative. + +The deprecation albel COULD be remain over multiple releases. As long as the deprecated code is used inside Friendica or the offical addon repository, it SHOULD NOT be hard deprecated. + +**2. Hard deprecation** + +If the deprecated code is no longer used inside Friendica or the offical addons it MUST be hard deprecated. The code MUST NOT be deleted. It MUST be stay for at least to the next major release. + +Hard deprecation code means that the code triggers an `E_USER_DEPRECATION` error if it is called. For instance with the deprecated class `Friendica\Core\Logger` the call of every method should be trigger an error: + +```php +/** + * Logger functions + * + * @deprecated 2025.02 Use constructor injection or `DI::logger()` instead + */ +class Logger { + public static function info(string $message, array $context = []) + { + trigger_error('Class `' . __CLASS__ . '` is deprecated since 2025.02 and will be removed in the next major release, use constructor injection or `DI::logger()` instead.', E_USER_DEPRECATED); + + self::getInstance()->info($message, $context); + } + + /* ... */ +} +``` + +This way the maintainer or users of addons will be notified that the addon will stop working in the next release. The addon maintainer now has the time until the next release to fix the deprecations. + +**3. Code Removing** + +Once a major release is published we as the Friendica maintainers can remove all code that is hard deprecated. From 34e6d29d1fd1a501bc15873434bf7445feccf1dd Mon Sep 17 00:00:00 2001 From: Artur Weigandt Date: Mon, 13 Jan 2025 23:56:27 +0100 Subject: [PATCH 2/6] Apply suggestions from code review --- doc/Developers-Intro.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/Developers-Intro.md b/doc/Developers-Intro.md index e37313c73f..d44a2c6224 100644 --- a/doc/Developers-Intro.md +++ b/doc/Developers-Intro.md @@ -170,7 +170,7 @@ Inspired by the [Symonfy BC promise](https://symfony.com/doc/current/contributin - Classes, interfaces, traits, enums, functions, methods, properties and constants marked as `@internal` or `@private` - Extending or modifying a `final` class or method in any way - Calling `private` methods (via Reflection) -- Accessing `private` propertyies (via Reflection) +- Accessing `private` properties (via Reflection) - Accessing `private` methods (via Reflection) - Accessing `private` constants (via Reflection) - New properties on overrided `protected` methods @@ -196,13 +196,13 @@ If we as the Friendica maintainers decide to remove some functions, classes, int class Logger {/* ... */} ``` -This way addons developers might be notified by their IDE or other tools that the usage of the class is deprecated. In Friendica we can now start to replace all occurences and usage of this class with the alternative. +This way addon developers might be notified by their IDE or other tools that the usage of the class is deprecated. In Friendica we can now start to replace all occurrences and usage of this class with the alternative. -The deprecation albel COULD be remain over multiple releases. As long as the deprecated code is used inside Friendica or the offical addon repository, it SHOULD NOT be hard deprecated. +The deprecation label COULD be remain over multiple releases. As long as the deprecated code is used inside Friendica or the official addon repository, it SHOULD NOT be hard deprecated. **2. Hard deprecation** -If the deprecated code is no longer used inside Friendica or the offical addons it MUST be hard deprecated. The code MUST NOT be deleted. It MUST be stay for at least to the next major release. +If the deprecated code is no longer used inside Friendica or the official addons it MUST be hard deprecated. The code MUST NOT be deleted. It MUST be stay for at least to the next major release. Hard deprecation code means that the code triggers an `E_USER_DEPRECATION` error if it is called. For instance with the deprecated class `Friendica\Core\Logger` the call of every method should be trigger an error: From 3801382ffe7c73826b09f3fcb1588961c35a3431 Mon Sep 17 00:00:00 2001 From: Artur Weigandt Date: Tue, 14 Jan 2025 19:52:03 +0100 Subject: [PATCH 3/6] Update doc/Developers-Intro.md --- doc/Developers-Intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/Developers-Intro.md b/doc/Developers-Intro.md index d44a2c6224..e9236f6934 100644 --- a/doc/Developers-Intro.md +++ b/doc/Developers-Intro.md @@ -163,7 +163,7 @@ If you are interested in improving those clients, please contact the developers Friendica can be extended by addons. These addons relies on many internal classes and conventions. As developers our work on Friendica should not break things in the addons without giving the addon maintainers a chance to fix their addons. Our goal is to build trust for the addon maintainers but also allow Friendica developers to move on. This is called the Backward Compatibility Promise. -We promise BC inside every major release. If one release breaks BC, this should considered as a bug and will be fix in a bugfix release. +We promise BC for deprecated code for at least 6 month. After this time the deprecated code will be remove with the next release. If a release breaks BC without deprecation, this SHOULD considered as a bug and BC SHOULD be restored in a bugfix release. Inspired by the [Symonfy BC promise](https://symfony.com/doc/current/contributing/code/bc.html) we promise BC for every class, interface, trait, enum, function, constant, etc., but with the exception of: From 3dc467e208ceae967e569809adabc09ab0476d93 Mon Sep 17 00:00:00 2001 From: Artur Weigandt Date: Tue, 14 Jan 2025 20:29:20 +0100 Subject: [PATCH 4/6] Increase BC to 6 months --- doc/Developers-Intro.md | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/doc/Developers-Intro.md b/doc/Developers-Intro.md index e9236f6934..39462d20f7 100644 --- a/doc/Developers-Intro.md +++ b/doc/Developers-Intro.md @@ -157,14 +157,12 @@ If you are interested in improving those clients, please contact the developers * SailfishOS: **Friendiy** [src](https://kirgroup.com/projects/fabrixxm/harbour-friendly) - developed by [Fabio](https://kirgroup.com/profile/fabrixxm/profile) * Windows: **Friendica Mobile** for Windows versions [before 8.1](http://windowsphone.com/s?appid=e3257730-c9cf-4935-9620-5261e3505c67) and [Windows 10](https://www.microsoft.com/store/apps/9nblggh0fhmn) - developed by [Gerhard Seeber](http://mozartweg.dyndns.org/friendica/profile/gerhard/profile) -## Backward compatability +## Backward compatibility ### Backward Compatibility Promise Friendica can be extended by addons. These addons relies on many internal classes and conventions. As developers our work on Friendica should not break things in the addons without giving the addon maintainers a chance to fix their addons. Our goal is to build trust for the addon maintainers but also allow Friendica developers to move on. This is called the Backward Compatibility Promise. -We promise BC for deprecated code for at least 6 month. After this time the deprecated code will be remove with the next release. If a release breaks BC without deprecation, this SHOULD considered as a bug and BC SHOULD be restored in a bugfix release. - Inspired by the [Symonfy BC promise](https://symfony.com/doc/current/contributing/code/bc.html) we promise BC for every class, interface, trait, enum, function, constant, etc., but with the exception of: - Classes, interfaces, traits, enums, functions, methods, properties and constants marked as `@internal` or `@private` @@ -173,12 +171,10 @@ Inspired by the [Symonfy BC promise](https://symfony.com/doc/current/contributin - Accessing `private` properties (via Reflection) - Accessing `private` methods (via Reflection) - Accessing `private` constants (via Reflection) -- New properties on overrided `protected` methods +- New properties on overridden `protected` methods - Possible name collisions with new methods in an extended class (addon developers should prefix their custom methods in the extending classes in an appropriate way) - Dropping support for every PHP version that has reached end of life -Breaking changes will be happen only in a new release but MUST be hard deprecated first. - ### Deprecation and removing features As the development goes by Friendica needs to get rid of old code and concepts. This will be done in 3 steps to give addon maintainer a chance to adjust their addons. @@ -196,13 +192,13 @@ If we as the Friendica maintainers decide to remove some functions, classes, int class Logger {/* ... */} ``` -This way addon developers might be notified by their IDE or other tools that the usage of the class is deprecated. In Friendica we can now start to replace all occurrences and usage of this class with the alternative. +This way addon developers might be notified early by their IDE or other tools that the usage of the class is deprecated. In Friendica we can now start to replace all occurrences and usage of this class with the alternative. -The deprecation label COULD be remain over multiple releases. As long as the deprecated code is used inside Friendica or the official addon repository, it SHOULD NOT be hard deprecated. +The deprecation label COULD be remain over multiple releases. As long as the `@deprecated` labeled code is used inside Friendica or the official addon repository, it SHOULD NOT be hard deprecated. **2. Hard deprecation** -If the deprecated code is no longer used inside Friendica or the official addons it MUST be hard deprecated. The code MUST NOT be deleted. It MUST be stay for at least to the next major release. +If the deprecated code is no longer used inside Friendica or the official addons it MUST be hard deprecated. The code MUST NOT be deleted. Starting from the next release, it MUST be stay for at least 6 months. Hard deprecated code COULD remain longer than 6 months, depending on when a release appears. Addon developer MUST NOT consider that they have more than 6 months to adjust their code. Hard deprecation code means that the code triggers an `E_USER_DEPRECATION` error if it is called. For instance with the deprecated class `Friendica\Core\Logger` the call of every method should be trigger an error: @@ -215,17 +211,23 @@ Hard deprecation code means that the code triggers an `E_USER_DEPRECATION` error class Logger { public static function info(string $message, array $context = []) { - trigger_error('Class `' . __CLASS__ . '` is deprecated since 2025.02 and will be removed in the next major release, use constructor injection or `DI::logger()` instead.', E_USER_DEPRECATED); + trigger_error('Class `' . __CLASS__ . '` is deprecated since 2025.05 and will be removed after 6 months, use constructor injection or `DI::logger()` instead.', E_USER_DEPRECATED); self::getInstance()->info($message, $context); } - /* ... */ + /* ... */ } ``` -This way the maintainer or users of addons will be notified that the addon will stop working in the next release. The addon maintainer now has the time until the next release to fix the deprecations. +This way the maintainer or users of addons will be notified that the addon will stop working in one of the next releases. The addon maintainer now has at least 6 months to fix the deprecations. + +Please note that the deprecation message contains the release that will be released next. In the example the code was hard deprecated in `2025.05` and COULD be removed earliest with the `2025.11` release. **3. Code Removing** -Once a major release is published we as the Friendica maintainers can remove all code that is hard deprecated. +We promise BC for deprecated code for at least 6 month, starting from the release the deprecation was announced. After this time the deprecated code COULD be remove within the next release. + +Breaking changes MUST be happen only in a new release but MUST be hard deprecated first. The BC promise refers only to releases, respective the `stable` branch. Deprecated code on other branches like `develop` or RC branches could be removed earlier. This is not a BC break as long as the release is published 6 months after the deprecation. + +If a release breaks BC without deprecation or earlier than 6 months, this SHOULD considered as a bug and BC SHOULD be restored in a bugfix release. From 11593bb88732f0dc97acc89c0e1d1bba6aa172f4 Mon Sep 17 00:00:00 2001 From: Artur Weigandt Date: Thu, 16 Jan 2025 16:07:32 +0100 Subject: [PATCH 5/6] Adjust fromat --- doc/Developers-Intro.md | 41 ++++++++++++++++++++++++++++++----------- 1 file changed, 30 insertions(+), 11 deletions(-) diff --git a/doc/Developers-Intro.md b/doc/Developers-Intro.md index 39462d20f7..f07b711648 100644 --- a/doc/Developers-Intro.md +++ b/doc/Developers-Intro.md @@ -161,7 +161,11 @@ If you are interested in improving those clients, please contact the developers ### Backward Compatibility Promise -Friendica can be extended by addons. These addons relies on many internal classes and conventions. As developers our work on Friendica should not break things in the addons without giving the addon maintainers a chance to fix their addons. Our goal is to build trust for the addon maintainers but also allow Friendica developers to move on. This is called the Backward Compatibility Promise. +Friendica can be extended by addons. +These addons relies on many classes and conventions from Friendica. +As developers our work on Friendica should not break things in the addons without giving the addon maintainers a chance to fix their addons. +Our goal is to build trust for the addon maintainers but also allow Friendica developers to move on. +This is called the Backward Compatibility Promise. Inspired by the [Symonfy BC promise](https://symfony.com/doc/current/contributing/code/bc.html) we promise BC for every class, interface, trait, enum, function, constant, etc., but with the exception of: @@ -177,11 +181,13 @@ Inspired by the [Symonfy BC promise](https://symfony.com/doc/current/contributin ### Deprecation and removing features -As the development goes by Friendica needs to get rid of old code and concepts. This will be done in 3 steps to give addon maintainer a chance to adjust their addons. +As the development goes by Friendica needs to get rid of old code and concepts. +This will be done in 3 steps to give addon maintainers a chance to adjust their addons. **1. Label deprecation** -If we as the Friendica maintainers decide to remove some functions, classes, interface, etc. we start this by adding a `@deprecated` PHPDoc note on the code. For instance the class `Friendica\Core\Logger` should be removed, so we add the following note with a possible replacement. +If we as the Friendica maintainers decide to remove some functions, classes, interface, etc. we start this by adding a `@deprecated` PHPDoc note on the code. +For instance the class `Friendica\Core\Logger` should be removed, so we add the following note with a possible replacement: ```php /** @@ -192,15 +198,22 @@ If we as the Friendica maintainers decide to remove some functions, classes, int class Logger {/* ... */} ``` -This way addon developers might be notified early by their IDE or other tools that the usage of the class is deprecated. In Friendica we can now start to replace all occurrences and usage of this class with the alternative. +This way addon developers might be notified early by their IDE or other tools that the usage of the class is deprecated. +In Friendica we can now start to replace all occurrences and usage of this class with the alternative. -The deprecation label COULD be remain over multiple releases. As long as the `@deprecated` labeled code is used inside Friendica or the official addon repository, it SHOULD NOT be hard deprecated. +The deprecation label COULD be remain over multiple releases. +As long as the code that is labeled with `@deprecated` is used inside Friendica or the official addon repository, it SHOULD NOT be hard deprecated. **2. Hard deprecation** -If the deprecated code is no longer used inside Friendica or the official addons it MUST be hard deprecated. The code MUST NOT be deleted. Starting from the next release, it MUST be stay for at least 6 months. Hard deprecated code COULD remain longer than 6 months, depending on when a release appears. Addon developer MUST NOT consider that they have more than 6 months to adjust their code. +If the deprecated code is no longer used inside Friendica or the official addons it MUST be hard deprecated. +The code MUST NOT be deleted. +Starting from the next release, it MUST be stay for at least 6 months. +Hard deprecated code COULD remain longer than 6 months, depending on when a release appears. +Addon developer MUST NOT consider that they have more than 6 months to adjust their code. -Hard deprecation code means that the code triggers an `E_USER_DEPRECATION` error if it is called. For instance with the deprecated class `Friendica\Core\Logger` the call of every method should be trigger an error: +Hard deprecation code means that the code triggers an `E_USER_DEPRECATION` error if it is called. +For instance with the deprecated class `Friendica\Core\Logger` the call of every method should be trigger an error: ```php /** @@ -220,14 +233,20 @@ class Logger { } ``` -This way the maintainer or users of addons will be notified that the addon will stop working in one of the next releases. The addon maintainer now has at least 6 months to fix the deprecations. +This way the maintainer or users of addons will be notified that the addon will stop working in one of the next releases. +The addon maintainer now has at least 6 months to fix the deprecations. -Please note that the deprecation message contains the release that will be released next. In the example the code was hard deprecated in `2025.05` and COULD be removed earliest with the `2025.11` release. +Please note that the deprecation message contains the release that will be released next. +In the example the code was hard deprecated in `2025.05` and COULD be removed earliest with the `2025.11` release. **3. Code Removing** -We promise BC for deprecated code for at least 6 month, starting from the release the deprecation was announced. After this time the deprecated code COULD be remove within the next release. +We promise BC for deprecated code for at least 6 months, starting from the release the deprecation was announced. +After this time the deprecated code COULD be remove within the next release. -Breaking changes MUST be happen only in a new release but MUST be hard deprecated first. The BC promise refers only to releases, respective the `stable` branch. Deprecated code on other branches like `develop` or RC branches could be removed earlier. This is not a BC break as long as the release is published 6 months after the deprecation. +Breaking changes MUST be happen only in a new release but MUST be hard deprecated first. +The BC promise refers only to releases, respective the `stable` branch. +Deprecated code on other branches like `develop` or RC branches could be removed earlier. +This is not a BC break as long as the release is published 6 months after the deprecation. If a release breaks BC without deprecation or earlier than 6 months, this SHOULD considered as a bug and BC SHOULD be restored in a bugfix release. From a6c1b2eaf3459b55cb7e477da6e6b7543a62e9fe Mon Sep 17 00:00:00 2001 From: Art4 Date: Wed, 22 Jan 2025 14:59:01 +0000 Subject: [PATCH 6/6] Change BC promise to 5 months, fix some wording --- doc/Developers-Intro.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/doc/Developers-Intro.md b/doc/Developers-Intro.md index f07b711648..99e84739d0 100644 --- a/doc/Developers-Intro.md +++ b/doc/Developers-Intro.md @@ -164,7 +164,7 @@ If you are interested in improving those clients, please contact the developers Friendica can be extended by addons. These addons relies on many classes and conventions from Friendica. As developers our work on Friendica should not break things in the addons without giving the addon maintainers a chance to fix their addons. -Our goal is to build trust for the addon maintainers but also allow Friendica developers to move on. +Our goal is to build trust for the addon maintainers but also allow Friendica developers to move on. This is called the Backward Compatibility Promise. Inspired by the [Symonfy BC promise](https://symfony.com/doc/current/contributing/code/bc.html) we promise BC for every class, interface, trait, enum, function, constant, etc., but with the exception of: @@ -208,12 +208,12 @@ As long as the code that is labeled with `@deprecated` is used inside Friendica If the deprecated code is no longer used inside Friendica or the official addons it MUST be hard deprecated. The code MUST NOT be deleted. -Starting from the next release, it MUST be stay for at least 6 months. -Hard deprecated code COULD remain longer than 6 months, depending on when a release appears. -Addon developer MUST NOT consider that they have more than 6 months to adjust their code. +Starting from the next release, it MUST be stay for at least 5 months. +Hard deprecated code COULD remain longer than 5 months, depending on when a release appears. +Addon developer MUST NOT consider that they have more than 5 months to adjust their code. Hard deprecation code means that the code triggers an `E_USER_DEPRECATION` error if it is called. -For instance with the deprecated class `Friendica\Core\Logger` the call of every method should be trigger an error: +For instance with the deprecated class `Friendica\Core\Logger` the call of every method should trigger an error: ```php /** @@ -224,7 +224,7 @@ For instance with the deprecated class `Friendica\Core\Logger` the call of every class Logger { public static function info(string $message, array $context = []) { - trigger_error('Class `' . __CLASS__ . '` is deprecated since 2025.05 and will be removed after 6 months, use constructor injection or `DI::logger()` instead.', E_USER_DEPRECATED); + trigger_error('Class `' . __CLASS__ . '` is deprecated since 2025.05 and will be removed after 5 months, use constructor injection or `DI::logger()` instead.', E_USER_DEPRECATED); self::getInstance()->info($message, $context); } @@ -234,19 +234,19 @@ class Logger { ``` This way the maintainer or users of addons will be notified that the addon will stop working in one of the next releases. -The addon maintainer now has at least 6 months to fix the deprecations. +The addon maintainer now has at least 5 months or at least one release to fix the deprecations. Please note that the deprecation message contains the release that will be released next. -In the example the code was hard deprecated in `2025.05` and COULD be removed earliest with the `2025.11` release. +In the example the code was hard deprecated with release `2025.05`, so it COULD be removed earliest with the `2025.11` release. **3. Code Removing** -We promise BC for deprecated code for at least 6 months, starting from the release the deprecation was announced. +We promise BC for deprecated code for at least 5 months, starting from the release the deprecation was announced. After this time the deprecated code COULD be remove within the next release. Breaking changes MUST be happen only in a new release but MUST be hard deprecated first. The BC promise refers only to releases, respective the `stable` branch. Deprecated code on other branches like `develop` or RC branches could be removed earlier. -This is not a BC break as long as the release is published 6 months after the deprecation. +This is not a BC break as long as the release will be published 5 months after the hard deprecation. -If a release breaks BC without deprecation or earlier than 6 months, this SHOULD considered as a bug and BC SHOULD be restored in a bugfix release. +If a release breaks BC without deprecation or earlier than 5 months, this SHOULD considered as a bug and BC SHOULD be restored in a bugfix release.