Creating Patches

[glenharvy]

Hi,

I really would like confirmation of my understanding regarding generating patches.

Can you please confirm that the IA project that you used to create your original distribution file must not be changed in any way when generating a patch. For example, you cannot add a new shortcut or even amend a current shortcut and then create a patch using the amended IA project and selecting the original distribution file created by the original IA project. In essence, you can only change the files that make up the contents/source of the IA project to generate a patch. Essentially the only thing you can and must change is the IA Projects Version number.

Further, if you wanted to add or change a shortcut (or any other MSICode for that matter), you must generate a full new distributable file even if the contents/source files remained the same as the original.

In other words, a patch does not patch the installer program, only it's contents/source files etc.

If the above is correct, then if you were to redesign the IA project MSICode, then you should always keep a copy of the IA project that you created a distribution with for future use if you ever wish to patch the source files and issue a specific patch for possibly a now outdated version.

[FrancescoT]

Dear Glenharvy,

you are all most correct but with few exceptions.

First of all, you must consider that patch build have to be used for minimal changes only. This means basically, that the project flow must be keept identical with all the projects involved with the path (base project and patch project/s).

Even the project version must be identical ( ... along with other settings that must keept be identical).
If you have a base project version 1.0, the version number must be keept identical with the patch.

Patches are built using binary differential scans and contain only the delta of the changes between the older setups and the newest setup.
In other words, it contains the binary difference only (source files and modification to the MSI db).

For example;
If your base package creates a shortcut, if you modify the shortcut name with the patch project script, you will have TWO shortcuts once the patch build is installed.

The modification to the MSI db are only applied at runtime (when the patch runs) but not stored into the original MSI db.

Finally, if you have to redesign the IA project MSICode, you must deploy a full update and always keep each project source copy; base, patch or update, within a unique project folder (... in a safe place for any possible future use).

Hope this clarify your doubt.

Regards

[glenharvy]

Thanks for the clarification. I think this means in practice, that if I want to issue a minor change to say one of my executables contained in my project and issue first of all a patch for the current Version 1.0.0.0 users and then a full blown installation for new users that includes the changed executable distrubuted via the patch then I need...

FOR THE INITIAL VERSION 1.0.0.0:
The original IA Project and all its components as well as a copy of the IA installer produced.
I then should never change that IA project contents, including the Project Version number.
I can replace my changed executable and then use the same IA project to create a patch that will update my end users copies.

FOR NEW USERS [To be known as Version 1.1.0.0]
I can copy the original IA Project from above and change the MSI Code if I wish. If I change for example a shortcut, I will end up with two 'versions' of my software in use. One with an extra shortcut. Probably not an advisable scenario however probably acceptable for short-term situations.
I copy all the components including the changed executable mentioned above into my new IA Projects path.
I can change the Project Number to Version 1.1.0.0
I then generate a full new distribution and let my new users download this one.
Obviously Version1.0.0.0 users could also 'upgrade' by installing this version as well.


Now, lets say I want to issue another minor change...

FOR USERS OF THE INITIAL VERSION 1.0.0.0:
Using the original IA Project, I just change the executable concerned and create another patch. I add that patch to the list of patches for that version.
QUESTION 1: To create this second patch, do I need to include the first patch as one of the Patch References. The original full distribution is obviously the first Patch Reference and I guess the first patch must be added here as the second.
QUESTION 2: If the end user has already applied the first patch, how does the end users installation detect that it only needs to download and install the second patch.

FOR USERS OF VERSION 1.1.0.0
Create a patch following the same logic as creating the patch establishing Version 1.1.0.0.

FOR NEW USERS [To be known as Version 1.2.0.0]
Follow the same logic as the creation of Version 1.1.0.0.

The above just keeps going on and on until of course it becomes ridiculously confusing and I issue a 'full' update that eliminates everyone that was using V1.0.0.0 et al.

Can you please confirm the above is correct as I need to issue a patch asap.

Thanks.

[FrancescoT]

Dear Glenharvy,

As I said previously, you must keep in mind that patches have to be used for minimal update only. You always have to consider that from the point of view of the MSI engine, when distributing a patch the version of the installation package does not change. Due of this, I can only suggest you to not follow the version schema you described with your last reply.

If you have:
- Project 1 (base project 1.0.0.0)
- Project 2 (first patch project to version 1.0.0.0)
- Project 3 (second patch project to version 1.0.0.0)

The patch relation references will be:
- Project 1 - No references
- Project 2 - Reference to Project 1 FULL BUILD
- Project 3 - Reference to Project 1 and Project 2 FULL BUILD

Users of version 1.0.0.0 can use Project 3 PATCH BUILD to have their product updated to last release.
New users can use the Project 3 FULL BUILD to have their product updated to last release.

Once you release a new version, say version 1.2.0.0, you should repeat the above schema once again from beginning (if you release patches for this new version as well).

If you have:
- Project 4 (base project 1.2.0.0)
- Project 5 (first patch project to version 1.2.0.0)
- Project 6 (second patch project to version 1.2.0.0)

The patch relation references will be:
- Project 4 - No references
- Project 5 - Reference to Project 4 FULL BUILD
- Project 6 - Reference to Project 4 and Project 5 FULL BUILD

Users of version 1.0.0.0 can use the Project 6 FULL BUILD to have their product updated to last release.
Users of version 1.2.0.0 can use Project 6 PATCH BUILD to have their product updated to last release.
New users can use the Project 6 FULL BUILD to have their product updated to last release.

QUESTION 2: If the end user has already applied the first patch, how does the end users installation detect that it only needs to download and install the second patch.

If your are distributing it as InstallAware WEB UPDATE, just define a new Update Packs for your applications on the field. An update can consist of any downloadable file, and will typically be a setup executable. An update could be a setup that doesn't update application binaries at all, but just runs, for instance, a SQL script to refresh a database. An update could even be a document that is opened with the default application it has been associated on the end-user system!

Please have a look at IA the documentation about "WEB UPDATE" for more details.

Hope this finally clarify your doubt.

Regards

[glenharvy]

First of all - I apologise if I was unable to satisfy myself after reading the white papers and the 3 threads your refer to in related threads. I was almost there however I needed confirmation before I unleash IA stuff-ups caused by my stupidity on my customer base.

I believe your above comment sets it all out in an excellent and unambiguous fashion and makes absolute sense to me. I can only recommend that your comment be turned into a 'sticky' and also incorporated into your documentation dated November 2007.

Thanks again and warm regards,

Glen Harvy.

[FrancescoT]

Dear Glen,

I'm happy you found my comment useful ... if I have to say the truth, personally I prefer to deploy full updates.

Thanks to you!

Regards