DTH Development

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.

I agree. This would greatly improve DT Register

A good example is the last four releases. Without elaborating let me just say that each of those releases introduced bugs as a result of "improvements" from the previous release. There was even one period where it was quite frustrating: there was micro-releases labelled "a" all the way to "f" I believe. I upgraded to a few of them, only to be told two weeks later that a new release was out "that all should upgrade to." About a month later another release came out that "all should upgrade to" owing to the bugs fixed. But again the analysis showed that those critical bugs necessitating the upgrade originated from the improvements made in the previous release.

It is unusual for a software product to have no stable release and only development releases. And its a shame because the underlying product is actually well designed. They just need to add some processes to address the fact that some customers value stability much more than new features. Maybe they are concerned that no one will upgrade if the release is stable but that's not the case. They just need to understand that some customers can't upgrade so easily and frequently and that when we go to the trouble we want a product that works. I would even be willing to pay double of what they are charging for such a stable release.

Of course, they think every release is stable when they release it. But history proves otherwise.

Second this.

Still waiting for an official response. Can we have fork the code in to a development and stable release? Speaking for myself I would gladly pay more if you could make this happen.

I too agree with this, I think it would be a great addition to dtregister as I as well seem to be constantly chasing gremlins.

This would be a welcome change.

This is absolutely needed. New features are great, but not at the cost of never being certain if the component will work. I have used this great component for five years for especially one quite big annual event and every year new features have caused big and time-consuming problems with registrations. DT Register is a VERY good component with great futures but the uncertainity whether or not things will work when registrations start streaming in takes away much of the joy right now, this could easely be fixed by separating bugfixes to stable releases from development releases.

Ben