I think this along with the use of git, is the fastest way to get what we need, which in my case is a) rapid development of the editor, along with b) the ability to roll-back when things break.
Workflow would be:
See an update.
Decide when to apply the update (maybe wait a few days if not interested in the risk.)
Commit with git to protect code.
Apply update.If things are not to your liking:
Download the version you want.
Install.
Roll git back to pre-update commit.
There is always a cost to asking developers for more stability. They will naturally slow down, thus negating one of Wappler’s advantages as a small business–speed, flexibility and EMBRACING risk rather than running away from it. Leave risk avoidance to the big guys–let them stifle innovation. Wappler is, and will continue to be, in competition with other providers, and the product is just not ready for the burden of improved stability…especially given that the wappler product updates in no way touch production unless the developer so chooses.
The team has already implemented the experimental process for major changes, which further gives us the ability to choose our risk tolerance.
Even the process of deciding that a release is stable introduces more process, testing and complexity. I’m also assuming (complete wild guess) that rolling back Wappler is not as simple as one might think since the resulting code gets modified. The version you roll back to doesn’t know what the next version did to the project code.
THREE GUYS…just THREE. I for one applaud and strive for the same in my business endeavors. Skip all the management headaches and just get things done.
OF COURSE, we need a way to protect our own needs as well, to which stability is more important. Git is the standard. If Wappler can add the ability to download versions, I think we’ll have a winning solution.
–Ken