Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Versioning information #14

Merged
merged 1 commit into from
Mar 25, 2024
+10 −0
Merged

Versioning information #14

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions node-red-node-wot/VERSIONING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
# Versioning

The package uses [semantic versioning](https://semver.org/) with the following meanings to different versions:

- Patch: Under the hood, documentation and UI annotation fixes:
- The user flow sees no change other than some human-readable text within Node-RED.
- Even if node-wot gets a major overhaul but nothing changes for the Node-RED user, this versioning applies. For example, changing to .value() function was a major change in node-wot but this would have no impact to the Node RED user.
Copy link
Contributor

@hidetak hidetak Mar 25, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for organizing this!

For example, if the node-wot used in the Node-RED flow on the server is upgraded to a version that requires .value(), would the client developer need to change the client implementation?
If the developer of the server and the developer of the client are different, the developer of the server created in Node-RED may need to notify the developer of the client, but if only the Patch version has changed, the developer of the server cannot determine if the client is affected. If only the Patch version has changed, it would be difficult for the server developer to determine if the client is affected or not.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the specific example of "For example, if the node-wot used in the Node-RED flow on the server is upgraded to a version that requires .value(), would the client developer need to change the client implementation?", there should be no change required.

In general, the server and client should never need to know the node-wot or node-red packaged version of each other. TD should be the only source of truth.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your response.

I understand that even if the server node-wot is a later version that supports .value(), the client node-wot can communicate with the pre .value() version.

I think the versioning policy you have created is fine.

- Of course, if there are incompatible changes in the node-wot to be incorporated: Raise Major.
- Minor: Adding new features that influence the Node RED UI and add new nodes, new configuration fields, more options to configuration fields. An existing user flow does not break nor sees any change.
- Major: Changing the existing features such as removing nodes, removing configuration settings. An existing user flow breaks and the user needs to manually do some changes.
Loading