Better update procedureI

I use a dtap street for my regular delphi development: develop/test/acceptance/production. It allows me to fix bugs found in the production environment without trouble for my development branch containing not production ready enhancements and changes. If there’s a new version of Delphi I get an update, install it in a test environment and after approval it’s been installed in my production street.

Now SC: I have a working application and I deployed it. I found some issues to solve. There’s a new version of sc. This version brings back old issues in my case: I cannot deploy it’s a showstopper. Of course i can reload from backup but the main issue is that you can never trust that your application will run in the future. Of course you will do everything possible to solve issues fast, but it’s not a very professional way and very hard to ‘sell’ to the management. In fact it’s deadly. If I would be able to install SC on two locations I would be able to test the new release first before I use it in my production environment. Now I have to ‘trust’ SC that the new version will not introduce new and old bugs. Or I have to stick with the current release for ever…

This is not the first post on this matter, I’ve read posts of others too. I sincerely hope that someone of the management of SC will overlook this issue. Again it’s deadly for professional developers. I need to be able to trust what I have.

albert drent
aducom software

Re: Better update procedureI

Hello,
your are right…
so I wait one week before I update (I’m not beta tester for SC) and I make a total backup of path V5/V6
So I’m able to go back to elder version.
You can never be sure. that there is not a new bug in SC…

Best regards
Uwe

Re: Better update procedureI

Let’s hope there will come a supported feature of rollback. I can save the db file containing the project, roll back the old source and restore db (otherwise my changes are lost)… Not a very convenient way. Best solutions is allowing more instances to run beside eachother on the same db imho. Thanks for your support.

Re: Better update procedureI

I agree.

I don’t suppose it would be easy for you development guys to implement, but it would be great to be able to have the option to install multiple versions of ScriptCase alongside one another.
Projects could be incremented to reflect the ScriptCase patches so you could access different versions of your project inside different versions of ScriptCase.
No changes to the practical licensing arrangements.
This would ensure that a fully functional project is not only protected but can continue to be developed in an older version of Scriptcase until you are happy to upgrade to a newer version of ScriptCase that you have tested and are happy with.
Old, deprecated versions of Scriptcase could then be uninstalled to manage the number of versions to a sensible level.

One of the FANTASTIC things about ScriptCase is the regular updates. As users we wouldn’t want to slow down the pace of development. You guys do a great job!

Re: Better update procedureI

I 2nd that!

Re: Better update procedureI

Hello,

I have just sent your suggestion to our development team.

regards,
Bernhard Bernsmann