This repo contains metadata related to LaunchDarkly SDKs.
The data is intended for consumption by downstream products and services.
Data Product | Description | Format |
---|---|---|
Database | Database containing data from which other products are derived. | sqlite3 |
SDK Names | SDK friendly names for display. | JSON |
SDK Releases | SDK major/minor releases with EOL dates. | JSON |
SDK Types | SDK types for categorization. | JSON |
SDK Features | SDK features, including version introduced/deprecated. | JSON |
SDK Languages | Programming languages associated with SDKs. | JSON |
SDK Repos | SDK source repositories | JSON |
This repo contains an sqlite database containing a snapshot of SDK metadata fetched from individual repos.
It also contains JSON files that are derived from the database. These are intended for consumption by downstream products and services.
The JSON data products live in products
and the schemas for them live in schemas
.
Data products can be validated against the schemas using ./scripts/ci/check-json-schemas.sh
on Linux.
Ensure that the JSON files are valid and formatted using ./scripts/ci/format-json.sh
.
To quickly create basic metadata for a new repo, run ./scripts/add-repo.sh <launchdarkly/repo-name>
. This will
clone the repo, check-in an .sdk_metadata.json
file, and create a PR.
The JSON products have an implicit 'v1' version.
The sqlite database has no versioning policy and may change schemas at any time.
If any JSON schema needs a breaking change, then we should probably handle it like so:
- Add a new
products/v2
directory andschemas/v2
directory as needed - Update
./scripts/generate-products.sh
to generate the new data products, and also keep generating the old ones so they remain up-to-date. - Have new applications consume
/products/v2/whatever.json
- Eventually, when/if all consumers have migrated, stop generating the old products. Don't delete them though, just in case something is intermittently using them that we've forgotten about.
- Changing the meaning of an existing field
- Changing the contents of an existing field in an incompatible way (like changing its type)
- Removing an existing field
- Probably other things that we haven't thought of
- Adding a new field
Consumers of SDK metadata include:
Are you a consumer? Add a link here to receive communications when new features/changes are coming.