Application versions

8

I don't see the use case. Before you are introducing something "dangerous" just export the application.
If there's a problem restore it. This isn't a problem as long as you haven't introduced a change which would require data to be deleted. But this is would apply to your suggestion, too.


If you would have separate systems, or at least databases, for each environment you could rely on the automatically created backups, which are created before importing a process. These are available in the context menu on the process element.

Kind regards,
Daniel

Here is the use case:

Now you have to export the app. Sure it's easy, but takes time. Many, many clicks. And you have to save the file. So, every version needs separate file. You have to manage the files. And importing the file is even more clicks.
With varsioning, you just press the back button, when:

Your formula stops working after few changes
You change your mind
The browser goes white and nothing works

Also, versioning would help with documenting the app/process.
The same way you guys document the BPS versions and log the changes.
I would like to have app/process versions, so I could document app/process changes for the users.
Instant change is great, but there is no version controll over it, so with many instant changes made by many admins there is often a mess.

Ok, based on your previous post I believed it would be used for production and not during development.

I my experience I either break something which is immediately visible and I therefore know what I've done or I couldn't tell when the breaking change has been added. Of course, with the previous version I could move back and test it until I found a working version. Even so I would still be lost because I don't know what actually broke. Maybe I would need to move forward again? I may still need to implement the changes I did before and fix the one thing which broke. Would this version only work for admins would we need to "republish" an old version as a new one? If this would be even possible. There are changes which can not be undone. Even by importing an old version.

I agree with you on the documenting changes stuff though. Especially if the process is part of an other system where the code/changes can be tracked in a versioning control. There have been a lot of times where I wished that I could serialize a process to compare a version against one in a version control or production against dev. Even if it would be only in a complex json/XML format.
The other option I would have liked to have to get the actual delta between two versions entries from the history which could be written to a file so it again could be part of a commit.

Kind regards,
Daniel

So - hope Webcon will listen to our voice... :-)

Forget what I've written I would be willing to pay for such a feature right now. :)