Since we are now heading towards the release of DMXControl 3.2.1, we have talked alot about things like feature freeze, beta test, release, bug tracker etc. in the news. But which steps are actually needed to publish a DMXControl 3 version? Where does the development begin, how is DMXControl 3 created and what is necessary for the release? The new version is reason enough to have a look at the development process of a DMXControl 3 version and to show you, what is actually behind it. Therefore, in todays first part of this multi-part news, we will look at the basics of a new version and the planning required for it. In the next news we will then focus on programming and the actual publishing process, i.e. the so-called QRM meeting, the creation, beta testing and deployment of the new version.
It depends on the version
The creation of a new version begins long before its release, sometimes years before. How long depends on whether it is a major version, so the second digit in the version number changes (3.X.0) or a minor version, so the third digit (3.2.X) changes. Major versions contain major new features such as the new Input Assignment or the Softdesk in version 3.2.0. Minor versions mainly contain improvements of existing functions, especially small innovations and bug fixes. We are working on one major release and one minor release in parallel. As soon after a major release (most recently version 3. 2. 0) has been published, development of the next major release (i.e. currently version 3.3.0) begins. The development of a new minor release begins after each release. So we are currently working on DMXControl 3.2.1 and DMXControl 3.3.0 in parallel.
In addition, there are sometimes features in a minor version that are being developed but are not yet stable for a release or were implemented so late that they are untested. In order not to interfere with the release of the minor version, these functions will be temporarily disabled until the release of the version is completed. This was for example the case with some Input Assignment Nodes in DMXControl 3.2.0, which are now submitted with DMXControl 3.2.1 and go through the normal test process here.
Planning is half the battle
Now that we have clarified what major and minor versions are in our system, it's still not clear what's actually inside each version. The developers plan this in an internal roadmap. As described in the previous section, major changes and functions are placed on a major version, medium to small functions are distributed across all versions. Which function will end up in the roadmap and in which version it will be released is usually clarified in the meetings at the annual DMXControl Projects e.V. meeting in the middle of the year and/or the developer meeting at the end of the year. However, the roadmap is not so rigid for the smaller functions that it cannot be changed in a next roadmap session. This is due to the fact that we are a hobby project and the developers should have the freedom to spontaneously implement things they are up for and that might not have been planned directly.
With the roadmap we have the planning of the new big features. However, this does not cover the individual features of the functions or problems that occurred in previous versions. That's why we have our bug tracker. It fulfills several functions at once. On the one hand, errors are collected here, which the community have found in the software. The bug tracker is also a core element in beta testing, because closed issues need to be checked to see if they have really been fixed, and if new bugs are found, they are also reported here. We need those tickets for the traceability of issues.
On the other hand, the bug tracker also serves to keep track of changes. If you have any improvements, you would like to see in DMXControl 3, you can note them here. But also the developers add tickets for new functions here (partly hidden), in order to log the progress of the work.
Now is planned but nothing has been implemented yet. Next week you'll find out how...