General information about the Web of Things can be found on https://www.w3.org/WoT/.
The main deliverable being developed in this repository is the WoT Scripting API Specification.
Releases for published versions are found in releases.
See the rationale.md for explanation on API design choices.
To make contributions, please refer to https://github.com/w3c/wotwg#contributing.
If you want to make a full text review on the spec or other files, follow the steps outlined here.
The specification uses WebIDL definitions, but TypeScript definititions are also available.
See https://www.w3.org/WoT/IG/wiki/WG_WoT_Scripting_API_WebConf.
We use labels to categorize our work items.
As discussed in the 27th February 2023 call, the task force decided to use a new versioning mechanism for the WoT Scripting API specification. In practice, we augment the current Typescript versioning with a more comprehensive tagging mechanism that takes into account also standard W3C process for publishing Notes. Each substantial change will trigger the creation of a git tag on the repository and when the Note is published it will trigger a full Github release. Substantial changes are anything that is not just an editorial or rephrasing of the current document content; examples of substantial changes are:
- Fixing an algorithm
- New function or change in the argument list of an existing function
- Introducing a new type
- Fixing WebIDL
- etc.
On the other hand, examples of non-substantial changes are:
- Typos in the document
- Introduce new examples or explanatory text
- Improve readability or document structure
In every circumstance, different substantial changes may be packed together in one single git tag if they are closely related or are merged in a short period (e.g. a day). Tags follow semantic versioning
major.minor.patch-[alpha].[id]
ididentifies the experimental revision of an ongoingmajory.minor.patchversion.
Here is an example of the process we will use:
- We publish the current document and tag it with 0.8.0
- Then we make some relevant changes (e.g. a bug fix)
- We tag version 0.8.1-alpha.1
- We continue fixing stuff
- Then we go for 0.8.1-alpha.2
- If we change the API (adding a new function) we should go for 0.9.0-alpha.1
- We can cycle in these changes as much as we want (e.g. 0.x.y-alpha.x)
- When we want to publish the document again we remove the alpha (e.g. assuming we were at 0.9.1-alpha.10 we release 0.9.1)
Since we are still in a exploratory phase, we will use the major number 0 until we reach a certain level of maturity.