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
{{ message }}
Repository navigation
Commit fa0155b
Browse filesBrowse the repository at this point in the historyBrowse files
Blueapi has [released versions](https://github.com/DiamondLightSource/blueapi/releases) that are complaint with [semantic versioning](https://semver.org/) to make updating/rolling back as easy as possible. Blueapi's [REST API](../reference/rest-spec.md) is versioned separately to the main application, since not all changes will affect it. The idea is that a change in the REST API version is a signal to client developers that they may need to do some work to update.
3
+
Blueapi has [released versions](https://github.com/DiamondLightSource/blueapi/releases) that are compliant with [semantic versioning](https://semver.org/) to make updating/rolling back as easy as possible. Blueapi's [REST API](../reference/rest-spec.md) is versioned separately to the main application, since not all changes will affect it. The idea is that a change in the REST API version is a signal to client developers that they may need to do some work to update.
4
4
5
5
If you are a developer contributing a PR, there is a unit test that will fail if the REST API has changed in your PR but the version defined in the code, [](#REST_API_VERSION), has not been updated. You should update the version for _any_ change to the API at all, whether it's a major, minor or patch update is to be determined by the developer(s) and the reviewer(s) involved. _Do not_ update [`docs/reference/openapi.yaml`](../reference/openapi.yaml), it is checked against `main` in CI.
Copy file name to clipboardExpand all lines: docs/explanations/events.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,14 +16,14 @@ a plan has started, finished, paused, errored etc. See the example below:
16
16

17
17
18
18
Note the gap between the start of the plan and the issue of the first [`run start document`](https://blueskyproject.io/event-model/main/user/explanations/data-model.html#run-start-document), and the similar gap
19
-
for the stop document vs end of the plan, thsse are typically used for setup and cleanup.
19
+
for the stop document vs end of the plan, these are typically used for setup and cleanup.
20
20
Also note that a plan can produce an arbitrary number of runs. This decoupling is fine in an IPython terminal
21
21
because a human user can see when a plan has started, can see when it's finished and can see which runs are
22
22
associated with which plans.
23
23
24
24
## New Events
25
25
26
-
For the case of automation, we introduce a new set of events outside of the event model, specifically
26
+
For the case of automation, we introduce a new set of events outside the event model, specifically
27
27
pertaining to the running of the plan and state of the `RunEngine`. At a minimum, an event is emitted
0 commit comments