chore(fcm): Deprecate sendToTopic and sendToCondition

[lahirumaramba]

• Mark legacy functions sendToTopic and sendToCondition as deprecated.
• Remove integration tests for FCM legacy (deprecated) APIs as these APIs will be removed in the upcoming major release.

[jonathanedey]

LGTM! Thanks

[ert78gb]

Sorry for commenting on closed PR, but deleting test of the deprecated API-s is not lucky, because the funtionality must work until the end of the life of the API(next major release).

[lahirumaramba]

Sorry for commenting on closed PR, but deleting test of the deprecated API-s is not lucky, because the funtionality must work until the end of the life of the API(next major release).

The SDK unfortunately do not have control over the BE REST endpoints. Please refer to the release notes and use the send() API instead the deprecated functions.

[ert78gb]

Yes, the SDK does not control the REST API endpoint. The SDK only warns to the users about the deprecation. This PR not just add deprecation info, but it removes tests too. If this SDK follows the semantic versioning then in the current major version (12) should not remove the test because it ensure every feature of the version 12 is working.

Maybe I am overthinking, but I always do the following procedure to decrease the chance of the unwanted breaking changes.
Because if someone do a code modification in the SDK that breaks the deprecated operations then it not ok, because it is just deprecated and not deleted, so it must work as-is.

1. API mark operations as deprecated
2. current release of the SDK mark operations as deprecated
3. delete the deprecated operations and relevant tests in the SDK.
4. release a new major version of the SDK. It is a clear indicator for every developer who follows the semantic versioning there is some breaking changes
5. delete operations in the API side

[lahirumaramba]

Yes, the SDK does not control the REST API endpoint. The SDK only warns to the users about the deprecation. This PR not just add deprecation info, but it removes tests too. If this SDK follows the semantic versioning then in the current major version (12) should not remove the test because it ensure every feature of the version 12 is working.

Maybe I am overthinking, but I always do the following procedure to decrease the chance of the unwanted breaking changes. Because if someone do a code modification in the SDK that breaks the deprecated operations then it not ok, because it is just deprecated and not deleted, so it must work as-is.

1. API mark operations as deprecated
2. current release of the SDK mark operations as deprecated
3. delete the deprecated operations and relevant tests in the SDK.
4. release a new major version of the SDK. It is a clear indicator for every developer who follows the semantic versioning there is some breaking changes
5. delete operations in the API side

You are right! I am not disagreeing with you on this.

The steps you have mentioned are what we have done in the past and what we will always try to follow. Unfortunately, in this specific case we are unable to get a major release out before the BE API starts limiting the usage of the deprecated APIs. As a result, the existing integration tests are failing in our SDK CIs blocking the release pipeline. I understand this is not the best approach and we try our best to present the alternatives such as the updated send() API to make is less annoying.