Since we are now aiming towards the release of DMXControl 3.2.1, we have talked a lot 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. In today's last part of this series we take a look at the beta test and the provision of a DMXControl version. If you want to read the previous parts again, we have linked them here:
At some point in time the features discussed in the QRM are implemented in DMXControl 3. Then the time has come to publish this DMXControl 3 version. Now two things happen. On the one hand, a so-called feature freeze is proclaimed among the developers. This means that no new functions may be added to the current version, but must be provided for the next version. Only errors may be corrected. On the other hand, the beta test now begins. Sometimes we even put the beta test a bit ahead of the feature freeze, so that the beta testers can start testing already finished functions. This means that a part is already processed when the feature freeze is called. It is also common that the beta testers get several betas (normally 3 to 4, sometimes much more for major releases) until a version is final and can be released.
For the beta test we have selected a group of users from the forum, of whom we have the impression that they really want to support us and who are also active in the forum constructively. We deliberately don't want to keep the group too large, so that we keep the direct line to the beta testers and so that joint meetings don't become too chaotic. The beta testers were also trained to systematically go through the things to be tested and to pay attention to certain behaviour patterns. But why do you need beta testers at all, when we wrote in the last part that we already look with more than 1600 tests at the creation if DMXControl 3 works? Beta testers take on several roles here. On the one hand, unlike automatic tests, they can assess whether the surface looks correct or whether there are display errors, for example. They can also check the functions of a surface or very special cases much better and faster than automatic tests. They also like to find logic errors in operation. Another main task of a beta tester with us is to check the changes. This means that the beta testers get an overview of the changes (the changelog) and then test them one by one to see if they work for them. For this purpose, the bug tracker entries frequently referenced to a change are also looked at and an attempt is made to reproduce or to test the new functions described therein. So a beta tester might get a new feature a little earlier than all the others. However, these pre-release versions can still be unstable and the whole thing involves a certain amount of work.
Last but not least, we also use the beta tester group to discuss new features with them. So we try to collect other opinions about a function outside of the club besides our internal QRM. Sometimes these are also things that we have already discussed controversially internally and then want further opinions. But also when it comes to estimating how well a function can be operated, we discuss this with the beta testers. As already described in the second part, such a discussion has, for example, resulted in the current version 3.2.0 in the operating concept of the Input Assignment being slightly revised again, and now has the current look and feel.
At this point we would like to thank again our active beta testers, who make sure with their work that DMXControl 3 is so stable and bugs keep within limits compared to the size of DMXControl 3.
If the beta testers are so far through and have no more complaints, the tested stand is taken and is the official release for this DMXControl 3 version. But now there is more work to be done. First, the now official installer must be uploaded to our homepage. We also set a release date within the team. This is usually a day on which news is usually published. Accordingly, the download manager on our homepage must be configured to release the installer at the right time. Further work is still to write the changelog for the current version together, to put it on the homepage and to have it published at the right time. Finally a release news has to be written in the release area. Then finally the time can come, long desired by you and by us, at which the DMXControl 3 version is published. But for us the work does not stop then, because after the release is before the release.
We hope you enjoyed this insight into our release machinery and you now have a better picture of what is needed until at the end a finished DMXControl 3 version can be found in the download area. We would like to know from you how you liked the format of the news series? Do you think we should use such a format again (if it fits) or do you have any suggestions for improvement? Just write it in the comments below 
Euer 
DMXControl-Team
JPK 
3
LightningBrothers 
3
LightningBrothers 2
Administrators DMXControl member
Comments
Newly created comments need to be manually approved before publication, other users cannot see this comment until it has been approved.
Newly created comments need to be manually approved before publication, other users cannot see this comment until it has been approved.