enforcer-99
Posts: 10
|
| Posted: 01/22/2009, 5:10 PM |
|
The last time I performed an update of CodeCharge Studio 4.x, it forced me to "upgrade" my applications to the new version. This caused me untold hours as I had to fix all kinds of things that suddenly broke due to the upgrade.
My question is: How are people approaching this for large applications? I've actually begun to build virtual machines and then install CodeCharge on them for each customer. Of course - I then need to purchase a perpetual license for each and then, for all time, that customer's product is using that version of CodeCharge (good for CodeCharge - bad for cash flow on my side). In a website with hundreds of pages I see no alternative. I certainly can't spend weeks testing and debugging after every upgrade (semi-monthly).
How are the rest of you dealing with these updates?
I really wish CodeCharge would just leave my applications alone. If I upgrade the IDE then why is it necessary to convert every page on the site to the new version? Why not just apply the changes to any pages I load in the IDE. This way, I can apply the fixes as I make changes to individual pages.
Thoughts?
Chip
|
 |
 |
MaFi
Posts: 49
|
| Posted: 01/23/2009, 12:13 AM |
|
Hi enforcer-99,
I have differnt CCS versions parallel running on my development system ( CCS2, 3.2 and 4.1).
For minor CCS updates eg I do a backup of the CCS system and projects to be able to revert the whole update. Than I republish the projects (F9) and check for problems. In most cases I have no problems with minor updates (sometimes with customized code).
Converting of projects to major new CCS versions (eg 3.2 -> 4.1) I do only when I have also major changes in the project. There you are right this takes a lot of time for testing and debugging.
Regards
Martin
|
|
|
|
E43509
Posts: 283
|
| Posted: 01/26/2009, 6:02 AM |
|
ughhh I have the same issue ... I have projects in v2, 3, & 4.
Some of them in v2 have a lot of behind the scenes code and when I've upgraded to the next release, I spend a lot of time getting things to work.
Right now I continue to maintain some of them in the earlier release and not upgrade.
|
|
|
|
whiterabbitwond
Posts: 28
|
| Posted: 03/25/2009, 12:04 PM |
|
I'll admit, I have a smaller setup. I develop one application for one client. Although it is a beast with a lot of custom code.
Because of weird quirks that CCS has had for as long as I've used it, and because of its lack of decent integration with subversion. This is what I do.
Any time I make a chunk of code changes, or upgrade, or do anything that ccs might choke on, I save the project, then zip the application folder. I setup winrar to automatically append a datetime stamp to the filename. So rightclicking the folder to zip takes about 2 seconds.
When I am actively coding, I save and zip about every 15 minutes. then reverting to a previous copy is as easy as closing ccs, and unzipping.
Each night all my zips are backed up offsite through jungledisk.
You may wonder why I backup so frequently. I love CCS for the time it saves me. But it is, and always has been flaky. Although version 4 has been much better. But even just this morning, I changed the base query on a record form to add some joins, and then changed it to use the custom update function. CTRL F8 to publish, and bang, "Unknown General Application Error". Wow, that helpful. And that permanently messed up that page. even when I changed back the query. That has happened so many times over the years that it does not even phase me. I just close CCS, 10sec later I am working on my last backup.
I say all this, because anyone actively coding in CCS is going to run into this. And a backup procedure like this works wonders with upgrades too. I have definitely had upgrades that totally borked an application because I was using some obscure function somewhere that it would happily toast. But, uninstall, revert to previous version. Revert to last backup. File bug report with CCS. And continue coding. All in about 15 minutes.
Happy coding,
David
|
|
|
|
|
