I've been a DTRegister user since 2009. I find myself having frequently having to upgrade DT Register, moreso I would say that other software packages.
Upgrading DT to a new release is a time consuming process. Who wants to keep upgrading a package that they bought, every month -- especially when the upgrade is not an automated process? The upgrade process is even more cumbersome for people who customized DT Register's code in some way. This is why I try to at all costs achieve what I want to achieve using the configuration or language files (so that I don't have to merge my code customizations following each upgrade). But in some cases, it is not possible to avoid code customization. The result is a series of upgrades that are unavoidable, and upgrades that take to much effort to implement.
After thinking about the root cause of this problem which I would summarize as too many needed upgrades without the corresponding utility, I've come to the conclusion that the root cause is that every new release contains both bug fixes AND improvements (such as new features).
But these improvements come at a cost. That cost being that the new code is likely to have bugs which will require still future upgrades to resolve. An improvement to the UI for instance, may make it easier for users to navigate, but the UI change is likely to introduce its own bugs, which will require users to upgrade to yet another future release to solve.
A common pattern to solve the problem of "too many upgrades without convergence to stability" is to have at least two code trees:
a) A development branch. This code tree contains your latest features. Ambitious users or those who need the new features can download this release with the understanding that there is some new code in this release that possibly hasn't been tested by a large number of people.
b) A stable code tree. For the most part only bug fixes are checked in to this code tree. Occassionally, well tested features from the development tree are merged into this tree (resulting in new, but well tested features). People who use this version have the confidence that all the code has been tested for sometime and that the release will work. Some software publishers even package the new features as a "release candidate" which eventually becomes the next stable release. Users who download the stable release understand they are not getting all the latest bells and whistles but willingly make the choice knowing that what they lose in features they will gain in stability.
In sum, I would like to see a code branch that mostly only has bug fixes rather than new features and another code branch with the latest features. This in my humble opinion would dramatically improve the DTRegister experience and reduce the number of times I have to install a new release from the current cycle of once few months to once a year.