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: docs/source/properties.rst
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -204,7 +204,8 @@ Note that the constraints for functional properties are set by assigning a dicti
204
204
205
205
.. note::
206
206
207
-
Property values are not validated when they are set directly, only via HTTP. This behaviour may change in the future.
207
+
Currently, property values are not validated when they are set directly in Python, only via HTTP.
208
+
Setting ``lt.FEATURE_FLAGS.validate_properties_on_set = True`` enables validation when they are set in Python. This may become default behaviour in the future.
LabThings allows some features to be turned on and off globally, using the `.FEATURE_FLAGS` object.
7
+
This was introduced as a way to smooth the upgrade process for downstream projects, meaning that when a new version of LabThings is released, they need not adopt all the new features at once.
8
+
9
+
Typically, your application will set the feature flags once, just after importing LabThings. For example, to validate properties when they are written to in Python, we would do:
When new features are intended to become non-optional, the usual procedure will be:
19
+
20
+
* Introduce the feature in a release, but disable it by default. It may be activated by setting a flag to `True`\ .
21
+
* At some point (either the release that introduces it, or a future release) a `DeprecationWarning` will be raised by relevant code if the feature has not been enabled.
22
+
* A subsequent release will enable the feature by default, but it may still be disabled by setting the flag to `False`\ . This will raise a `DeprecationWarning`\ .
23
+
* Another release will remove the feature flag and the feature will be permanently enabled.
24
+
25
+
Introducing a feature that's disabled by default, and adding `DeprecationWarning`\ s, are not "breaking changes" as they require no change to downstream code.
26
+
Enabling a feature by default, or removing the ability to disable a feature, would constitute a "breaking change".
27
+
While our major version is zero, the intention is that patch releases (e.g. ```0.1.0``` to ``0.1.1``) should not make breaking changes, but minor releases (e.g. ``0.1.0`` to ``0.2.0``) may do so.
28
+
After `v1.0.0` LabThings should follow the Semantic Versioning convention and make breaking changes only when the major version changes.
0 commit comments