...
The Things Stack is an Open Source project (excluded some proprietary features), allowing anyone to look into the source code, the issues the team is working on and the release notes of each release.
Patch, Minor and Major
...
Releases
There is We make a distinction between Patch, Minor releases and Major releases. Minor Patch releases, e.g. version 3.8.4 to version 3.8.5 contain compatible features and fixes. Meaning that no action is required from the user to keep the Network Server’s operations running as expected.
Major Minor releases, e.g. version 3.8.5 to version 3.9 may will contain breaking features for which the customer may need to perform an action to keep all operations running as expected. If a major new features that may require user action to enable. It may also contain (only) security fixes that may break existing operation. If a minor release contains a breaking change, the user is informed at least 5 working days in advance about the breaking change/additional configuration required and instructions are communicated to be executed by the user.
| Info |
|---|
Example of a breaking feature security fix in the major minor release to version 3.9: “Option to allow unauthenticated LoRa Basic Station connections ( |
All breaking functional changes (that are not security fixes) will only be targeted to our next Major release, i.e., v4.
Deployment cycles
The Things Industries team works in short sprints and aims for a deployment every 2 weeks. These deployments contain new features and bug fixes which are run through automated tests to check for compatibility and regression (for more information, see Section 2, Test Process).
...
If any noticeable downtime is expected during the deployment process or maintenance activity, customers are informed at least 5 working days in advance. This is done by adding an update on The Things Industries Status Page with information on the starting date and time, the duration of the update and the affected software components and server clusters. Notifications are sent to the subscribers of the status page when the deployment or maintenance is scheduled, and when the update is about to start and when it is completed.
Section 2. Test Process
During the development process, 4 2 type of tests are executed.
...
End-to-end tests
Smoke tests
Physical tests
...
End-to-end tests
Before any feature or bug fix is merged with the upcoming deployment branch, automated unit tests are executed. These test validate the workings of the feature, and compatibility with all network server components it interacts with.
End-to-end tests
In addition to Unit tests, end-to-end tests are executed to mimic user behaviortest compatibility and regression. End-to-end tests are designed to run through specific user scenarios the feature has been designed for. Tools are used to automate various interactions (e.g. clicking buttons, typing in forms, navigating via links, etc). After every change to The Things Stack, tests are run to validate the successful execution of the new feature or bug fix.
Smoke tests
The Things Industries distinguishes regular end-to-end tests from smoke tests. While regular end-to-end tests are scoped to a specific view or component and tests those in depth, smoke tests are testing mimic user behavior and to simulate different LoRaWAN scenarios. User behavior scenarios contain complete user stories that are critical to the overall integrity of the application and usually comprise multiple components and views (e.g. login flow, user registration or creation of applications). More information on the test processcreating applications, registering gateways, changing device settings etc). The LoRaWAN end-to-end test validate compatibility and test regressions by simulating scenarios such as sending uplinks and downlinks and process join requests.
Physical tests
When the previous end-to-end tests are completed, the new feature can be merged to the upcoming deployment branch. The release cycle starts with deploying The Things Stack, including its newly merged features to the staging environment. Only when the staging environment passes all physical tests, a release is planned for the production environment.
The Things Industries operates a physical test lab, containing multiple gateways and devices which continuously run LoRaWAN test loops. These test loops include:
Sending uplinks.
Receiving downlinks.
Testing operations mode class A and C.
Running through the join process for a Cluster Join Server and the Global Join Server.
Testing integrations using HTTP Webhooks, MQTT and Pub/Subs.
Exchanging traffic between different tenants within The Things Stack Cloud hosted, and between dedicated The Things Stack deployments using the Packet Broker.
All of these loops are tested using For the physical tests, gateways which run the UDP Packet Forwarder as well as LoRa Basics Station are used.
Section 3. Incident Management Process
...