Create a feature branch to start working on ably-go v2.0.0

[Rosalita]

The driving reason to start work on a v2.0.0 release is that it would be possible to make breaking changes to the existing project code.

A v2.0.0 release would allow us to implement Proposal: API redesign

There are a number of questions and considerations to think about before starting the work to redesign the API.

• Firstly the effort involved in completing this work is currently unknown so it should be started on a feature branch so that if we need to make any more v1.2.x releases before v2.0.0 is completed, we can. The trade off for starting work on a feature branch is that we will have to keep the feature branch updated by continuously merged code from the main branch into it to prevent it from becoming stale. There is an overhead for long lived feature branches in terms of keeping them up to date. We can mitigate against the toil of constantly updating a long lived branch by ceasing active development of new features on the main branch until the v2.0.0 feature is complete.
• The proposed API redesign still has outstanding questions around how pagination will be mockable. Pagination currently uses 6 different cursors, two types of cursors (items and pages) for three different types stats, messages and presence. There is a question here as to whether we want to use generics (a new feature in Go 1.18) to solve this problem. Generics would allow us to describe the process of pagination once then apply it to the three different types, as oppose to how the current API describes pagination three times, once for each type.
• If we do want to use generics, there was a warning in the release notes of Go 1.18 to use caution when deploying generics code to production as the feature is very new. However Go 1.19 is due to be released in August 2022 and we know that currently Go 1.19 fixes 5 or 6 generics issues including a fix to the generics syntax specification. Generics were designed for the type of problem that we have with pagination (duplication of code for multiple types) however I would hold off using them at least until Go 1.19 has been released with the fixes to both functionality and syntax.
• Following on from potentially using the new generics feature in a v2.0.0 release, another question comes up in terms of which Go version(s) a v2.0.0 release would support. If the latest generics code from 1.19 was to be used in creating v2.0.0 then this version would go against what we say in the readme about supporting the previous two versions of Go.

Only when we have considered these limitations and answered these questions should we start development of ably-go v2.0.0 on a new feature branch.

┆Issue is synchronized with this Jira Task by Unito