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. After we talked about the planning of a new version last week (read here again: Developer News - 20_KW08 - How does it work, a release? ( Part 1)), we are now dealing with the core part: the actual development. Then in further news the so-called QRM meeting, the production of a new DMXControl 3 version, the beta test and the providing of the Installer will follow.
Anyone who has ever programmed knows that this activity is one of the unspectacular ones. There is no banging or stinking (at most the heads are smoking), there are no sore muscles that you could feel from heavy, physical work, you sit for hours in a darkened room in front of the screen (see our DevCon pictures), a lot of "text" is typed on the keyboard and in the end the developer is happy because a control element can finally turn 
Often it takes a long time until you see anything of a new function at all, because a lot of internal preparations have to be done first. And if things are changed in the substructure of DMXControl 3, there is even sometimes no change at all on the GUI, because "only" an internal interface is now better defined or the software has become more efficient and therefore faster at a certain program part. That's why the programming part of our development process is not often shown in our news because there's simply nothing to show. Nevertheless, this is the most important part in the development of DMXControl 3.
But how do we work if the functions are planned as shown in the last part? Our Developers usually start writing code and programming functions in parallel with the planning. So partly on the two meetings (annual DMXControl meeting and developer meeting) but the major part of the programming is done at home. The developers spend quite frequently between one and three (or also more) hours per day of their spare time to work on DMXControl 3. But DMXControl Projects e.V. members have the freedom to organize their work as they wish. So it can also happen that the integration of new functions takes several weeks or months because the necessary free time for the implementation is not available. On the other hand, it also happens from time to time that you talk with a developer at our annual DMXControl meeting just before lunch about a missing feature for a certain use case. After lunch, the developer comes to meet you with an empty plate in his hand and says he has quickly implemented this feature and that you should test it. This shows that it is also important to us that the developers have the freedom to spontaneously implement things they would like to or which they need for their own events. What would be unthinkable in a project in a company keeps the fun of programming for the developers. The finding of solutions for new functions also contributes to this. So the developers want to have the freedom to implement things in their own way and to sometimes ignore suggested solutions in a bugtracker ticket. But, of course the fact that the developers know the structure of DMXControl 3 and know best of all what can be implemented and what not contribute to this as well.
Even if the saying of the heading to this section is only applicable to some areas of life, it is certainly true for our programming. Of course the developers have much experience with C#, the programming language in which DMXControl 3 is written. Besides, they know the software structure of DMXControl 3 pretty well. But sometimes you just have to try out how something can be implemented in the best way. Often there are several ways to integrate a functionality in DMXControl 3 and then it is to be tried out which variant is the best. An example for this is the new Input Assignment in DMXControl 3.2, where among other things the operating concept for the cuelist nodes was changed after a livestream session with the developers, people from the marketing team and the beta testers. That may have taken some additional time. However, a more flexible variant was added to the release, which only became apparent during the discussion.
Even if, in favourable cases, it is possible to work on an isolated area of the software which does not influence other areas, all the work of the developers must be brought together. As already reported elsewhere, we use our own Git server to manage our internal software repositories (read here again: Developer news - 18_KW23 - Internal Git migration of DMXControl 3 completed!) Apart from the usual advantages of such a version management (e.g. changes can be better tracked and, if necessary, reversed), it also ensures that the developers can work together, although we live all across Germany and only see each other at our two meetings. With this setup all code changes of the developers end up in the internal git, from where our Jenkins (what that is we'll look at in a later news) can get the latest version.
How it goes on, when the first implementation is finished and a function can be presented internally, you will find out next week...
Your 
DMXControl-Team
JPK 
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.