Context and objective
This document is a working draft for what users of the language bindings, or SDKs (for example the , ,) would expec would expect of a 1.0.0/Stable release and be used as a punchlist to track the work needed to reach those criteria.
This document can potentially be extended subsequently to help qualify other Symphony API language bindings that would be built by the community.
Current projects recap
| SDK | Project | Status | Project owner | |
|---|---|---|---|---|
| Java | Former user (Deleted) | |||
| .NET | Former user (Deleted) | |||
| Python | Matt Joyce (Deactivated) |
Users expectations
As users of a "1.0" SDK, I would expect the following:
- Supported by LLC
- At this stage in the growth/maturation of the Symphony Product, Ecosystem, and Community, users of the Java SDK who are also Symphony customers will expect using the SDK to be fully supported by Symphony LLC. This means:
- questions to the Symphony support organization (developers@symphony.com) are solved following the normal SLA
- using the SDK is fully documented on the central documentation for developers on the Symphony Platform https://developers.symphony.com/
- At this stage in the growth/maturation of the Symphony Product, Ecosystem, and Community, users of the Java SDK who are also Symphony customers will expect using the SDK to be fully supported by Symphony LLC. This means:
- Functional integrity
- functional coverage of public REST API, as documented on https://developers.symphony.com/ is complete and aligned with a specific Symphony Release number, ideally the most recent one
- Documentation integrity
- Documentation in the code itself (readme.md) is aligned with the other documentation (https://developers.symphony.com/) on nomenclature, terminology, links, etc
- Quality standards
- Functional quality: All public functions of the REST API is working as expected
- Non-functional quality: API performance is as expected and works in the most common deployment scenarios
More precisely, to meet those expectations, this would be the "launch readiness" punchlist we need to execute:
Launch readiness punchlist
- Foundation contribution criteria
- Quality Acceptance Criteria
- Security Acceptance Criteria
- Need to discuss what "SHOULD" criteria should be added if not already met
- Functional coverage meets, at time of release
- 0 Blockers on any functions
- 0 Critical on any functions
- 0 Major on any functions
- Need to discuss specific criticality definition
- Non-functional definition
- Need to discuss what we recommend here, notably vs load balancing, HA, supported topologies, etc
- Functional integrity
- LLC to perform deep dive
- LLC to publish Set Presence endpoint
- Documentation integrity
- LLC to perform deep dive
- LLC to add SDK documentation into https://developers.symphony.com/
Launch activities
- All users of the Symphony Platform should be made aware of this significant milestone. For example:
- Outreach to dev@symphony.foundation
- Outreach to Symphony LLC customers
- Other media (eg Twitter)