Limited Distribution

[rkligman]

It's time to produce a new update. I'd love to either 1) Have only a few updates go out in case of a problem and/or 2) Have it picked up slowly so the server doesn't get overwhelmed and/or support in the case of the update being a problem.

Does TU2 offer some sort of method to make any of this happen? I guess a followup question is: Is there a way to post the Update in the Live Area so that *I* can test the update instead of it being in the Test Area?

[Mark]

It's time to produce a new update. I'd love to either 1) Have only a few updates go out in case of a problem and/or 2) Have it picked up slowly so the server doesn't get overwhelmed and/or support in the case of the update being a problem.

TrueUpdate 2.0 does not have any of the two features that you ask about, but was designed to handle both situations.

The nice thing about TrueUpdate 2.0 is that if there is a problem with your update, you will just have to fix it and build your TureUpdate project again. Then the next time anyone checks for an update they will have access to the fixed update.

The best way to avoid this issue is to test your Update rigorously and on as many different test computers as possible.

2) Since users generally do not all update at the same time (i.e. they update when they run the software) this generally isn't an issue, but if you are concerned about server load simply use redundant TrueUpdate servers to compensate. If a server is unavailable for any reason, the client will move on to the next one until it can establish a connection.


Does TU2 offer some sort of method to make any of this happen? I guess a followup question is: Is there a way to post the Update in the Live Area so that *I* can test the update instead of it being in the Test Area?

TrueUpdate 2.0 does not have any built-in features that will allow you to accomplish this, however since you have total control over the Server script anything is possible.

The best way to accomplish what you are after would be to use two separate servers (as you implied), a “test” server and a “live” server. Simply upload to the test servers during the test phase, and test with clients that are aware of the test server. Then once the testing has completed upload to the "live" server to make the update available to your users.

[bnkrazy]

I use ini files to check for the current version, etc, and include an [Admin] section with a Testing=True key/value pair, that way I can force an update for my testers only to test with on our machines.

Since the users don't have an [Admin] section with the Testing=True setting, they would not be informed of the new version existing...

[rkligman]

After setting up my second client update project with TU, I had to reread some of the manual and also because I had problems with the HTTP, I was digging around in the code. What I've discovered that wasn't very obvious to start with is that the scripting is where the power of all this is.

As you said, BNKrazy, you can read INI files and more. When I start thinking about the possiblities, whoa. I mean simple concepts like the fact that you can have more than just a Client and Server script in the file to add new kinds of update logic are huge. It's those kind of details that don't immediately jump out at you when you first try out and use the product.

Thanks for both the responses. They are helping to make things clear.

[bnkrazy]

Heh, thats pretty much the same thing I did after my first 'test' project. Now I have about 20 global functions and 5 script tabs so the logic is really broken down to manageable chunks. It is really easy to maintain now.

Have fun!