Removing updates

I'm not quite sure what you're asking. Is it that you have a lot of versions and when you build your updates you have tens or hundreds of patch files and you'd like to whittle that down to only 1 or 2?

Correct. That is not the reason for me doing it but that is what I am trying to accomplish. Is it possible to keep a select list of updates?

That is not the reason for me doing it ...

Well, if you tell me the reason I'll be able to give you a better answer.

In wyBuild 2.7.0 (coming soon) we're adding "incremental patch". This means wyBuild will be able to create a patch from just the previous version to the latest version. And wyUpdate will instead download all update files version from there current version to the latest version to get to the latest version. This means you'll only have to upload a couple of update files on every new version (instead of hundreds or thousands of update files for every new version).

Does that make sense?

Yes I have seen talk of that before but I need to figure out a solution ASAP. With my application I have a client-server architecture in which the server will always have connection remotely (via HTTP and FTP) but not the client (due to security reasons with the companies I work with). So the only way to get updates to these clients are through the servers. With that said I planned to include all the client's updates inside of each server update and in every updated version of the server's installer. As you can see if I end up with numerous updates it can possibly increase the overall size of the server's installation package which I am trying to allude and also decrease the manageability of server/client updates. So that's why I am wondering if its possible to just keep only the most recent wyu (application_here.all.to.latest_version_here.wyu), or something of that nature to decrease the amount of updates I can to package with the server. Does that make sense? I apologize for not being clear before.

So that's why I am wondering if its possible to just keep only the most recent wyu (application_here.all.to.latest_version_here.wyu), or something of that nature to decrease the amount of updates I can to package with the server.

Not yet. Deleting all files except *.all.to.latest.wyu won't have the effect you're looking for.

With that said I planned to include all the client's updates inside of each server update and in every updated version of the server's installer.

Can't the server act as a proxy? That is, if the server can contact outside the company, and the clients can talk to the server, why can't the server forward any requests from the client and downlod the updates for the clients.

Or, I suppose the better question is: do you need an easy way for administrators to distribute updates to locked-down systems? Is that the ultimate end-goal?

Or, I suppose the better question is: do you need an easy way for administrators to distribute updates to locked-down systems? Is that the ultimate end-goal?

Yes it is.

In wyBuild 2.7.x we're adding a "admin update manager" program, and pre-built Windows services that you can install on the client machines. This way you'll have a drop-in solution for both the admin and client computers.

This isn't coming with 2.7.0, though. However we're shooting for shortly after 2.7.0.

So there is no way to accomplish this in the current version? No way to mimic this?

Yes, but as I suggested, you'll have to create an admin service that accepts HTTP requests from the client machines, downloads the appropriate update file on your server, and then forwards that file to the client machine.

Yes, but as I suggested, you'll have to create an admin service that accepts HTTP requests from the client machines, downloads the appropriate update file on your server, and then forwards that file to the client machine.

Sorry maybe I left it out before but I actually wanted to store the client's updates on the server that way the server would have all the updates that client needs. I know that is possible due to the file:// location that you can pass in as a download site. My only problem with that is that I wanted to reduce the amount of updates the server had to keep hold of. So in this current version, due to your previous comments, that means there is no way to accomplish that?

So instead of the updates being hosted on a remote website or server, and the local server acting as a proxy for the client to get to those updates, I wanted to have the local server host the updates for the client. I was just trying to figure out a way to decrease the amount of updates the local server has to hold.

So in this current version, due to your previous comments, that means there is no way to accomplish that?

You could take hybrid approach. Include the latest patches with your server and then if one of the client computers requests an older patch, download it once and cache it, then transfer it to the client. Then subsequent requests for the old file will already be on the server computer.

So in this current version, due to your previous comments, that means there is no way to accomplish that?

No good way, not yet.

Do you have a timeframe around the expectancy of a stable 2.7?

We're pushing hard for the new date: end of April. We think we can make it with the features we have planned.

Ok thanks, I just wanted to ready to plan for it.

Is 2.7 ever coming out? I've been hoping to get incremental patches for a long time now.

Yes, it's coming out. It has been delayed (obviously) due to bug fixes (some nasty bugs) and behind the scene process fixes.

Just following up to see if 2.7 is ever coming out? It's been over 2 years since I asked originally.

Yes, it's being worked on. This has been covered in several threads.