You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+68Lines changed: 68 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -65,6 +65,74 @@ Historically, before the above guidance was established - in particular around _
65
65
This left us open to the problem that client library references to spec items could end up semantically invalid if that spec point was re-used later.
66
66
For example, if `XXX1a` and `XXX1c` exist but `XXX1b` doesn’t because it was removed in the past (prior to this guidance being established), then we should introduce `XXX1d` for the new spec item rather than re-using `XXX1b`.
67
67
68
+
## SDK API docstrings
69
+
70
+
The `api-docstrings.md` file is a set of language-agnostic reference API commentaries for SDK developers to use when adding docstring comments to Ably SDKs. For new fields, this file should be modified in the same PR that makes the spec changes for those fields.
71
+
72
+
Modifications should obey the following conventions:
73
+
74
+
### Table format
75
+
76
+
#### Classes
77
+
78
+
The table for each class contains the following columns:
* If a method references its own class, it should just be code formatted, and not link to itself.
126
+
* Descriptions can link out to conceptual docs hosted on `ably.com/docs`, but should never link to the API references hosted there.
127
+
* A class or object should always be capitalized.
128
+
* Methods and parameters should always be lower-case.
129
+
* If adding a method/property to separate REST and realtime classes, ensure the descriptions are consistent (where possible).
130
+
* When a return value is returned in a paginated list, the description should link to the PaginatedResult class, as well as the class of whatever is returned.
131
+
* Items deprecated in the features spec should include the following text at the beginning of the description: `DEPRECATED: this <property/method> is deprecated and will be removed in a future version.`
132
+
* Default values should be listed in the description field.
133
+
* If a minimum or maximum value exists for a parameter then it should be listed in the description field.
134
+
* Time values should be referred to as `milliseconds since the Unix epoch` where applicable.
135
+
68
136
## Release Process
69
137
70
138
Use our standard [Release Process](https://github.com/ably/engineering/blob/main/sdk/releases.md#release-process), where:
0 commit comments