Choose version

[elias]

Hi!

I have one question regarding Visual Patch.

Is it possible for the user to choose what version (I have severals in the patch) he or she wants to install?

Sorry but I could not find that option anywhere.


Thanks in advance!

Elias

[elias]

No answers?

[Corey]

Hi. Typically full history patches are used to "bring all prior versions up to the latest version". But you can easily make different patches for different versions which your users can select from them as they please. That's the most efficient method in your case because there's no point in distributing versions which the user doesn't want, i.e. if your end user wants to update to version 2.0 of your product, then it would be inefficient to give them a patch which also contains versions 2.5, 3.0, and 3.5. :yes

At the same time it's important for the version 2.0 patch to contain the neccesary data to update "all previous versions" such as 1.0, 1.1, 1.5, etc. That's where Visual Patch 2.0 really shines. It's super fast, super accurate, and super reliable. :yes

Hope that helps. :)

[elias]

Thanks for the answer!

The thing is that I want the user to be able to choose whether he wants to use version 1.0, 2.0 or 3.0, and all that in one patch file.
I don't want different patches for different versions, just a all-in-one patch.

Is that possible with Visual Patch 2.0?

/Elias

[Corey]

Yes, Visual Patch creates full history patches. For most scenarios people don't distribute "extra" versions which the end user isn't installing.

[elias]

Sounds great, but how do I do it?
I have tried to see where that function is, but can't find it anywhere.
Help are appreciated.

Thanks!

[Corey]

Hi. Visual Patch creates full history patches, that's basically the industry standard, which means "update any previous version to current version". There's no demand for patches which carry "extra" versions that the end user doesn't wish to install. That wouldn't make any sense from a production or distribution standpoint, so as far as I know, no patching tool is designed to do that. I could be wrong though...

The goal in patching as I understand it is to distribute the "highest version the user plans on installing". If you want to create patches to update "multiple lower versions" then it would seem the best way to achieve that is to split your versions into patches and distribute them accordingly, i.e. supply each user with the patch that contains the highest version they wish to install. After all, why would you want to distribute versions that people aren't going to install? :yes

Anyhow I'm not a total Visual Patch expert, feel free to open a support ticket if you need a definitive answer to your question at http://support.indigorose.com :yes

If you visit our patches section you will see that this is how we have it arranged BTW. Notice there is one patch for AMS 4.0, a different one for AMS 5.0, etc. It's more efficient this way. In terms of point releases the goal for developers is always to get people up to the latest version, so there's really no demand for patches which bring people "back" to a given point release. If there were, I believe that would be a separate patch which would only be sent out by support staff in special cases. :yes

[elias]

Okey.
I appreciate your answers, but it seems Visual Patch doesn't have the futures I demand.

I may give the support a question as you said.

Thanks for your help, Corey!

[Corey]

Thanks for your help, Corey!

No problem. :)

[bnkrazy]

If I understand your goal, you want to be able for the user to upgrade to the most current version of your software, but to be able to stay within version 1, 2, 3, n, etc if desired.

Corey is correct in that most of the time you use patches to upgrade from any older version to the most current version, however I can see where there are situations where staying within the 'major' release version is desired.

In this case, TrueUpdate along with VisualPatch are your new friends. ;)

I would create a seperate patch for every major version of your software. Then, use TrueUpdate to create a nice front-end for the user to choose (or detect) what version he has installed and then download the patch that corresponds to his major version. This saves bandwidth as Corey mentioned by not including more in the patch than is necessary and the TrueUpdate process is flexible enough to support whatever updating scheme you can dream up. Have fun! :yes

[Corey]

That's good advice. :)