Small Updates can include and repair a large number of files
DGSchneider
languages by automating Orca and it has been working fine. The Small
Updates are applied correctly and so on...
The definition of a Small Update is "A small update makes changes to
one or more application files that are judged to be too minor to
warrant changing the product code."
http://msdn2.microsoft.com/en-us/library/aa371855.aspx
I am also aware of the "Changing the Product Code" rules listed in the
Help
http://msdn2.microsoft.com/en-us/library/aa367850.aspx
The question I have is regarding the statement "to one or more
application files".
I have been using Small Updates to change over 250 files, and I never
found a problem with the Small Updates. The file's sizes range from 10
KB to 70,861KB. The average MSP is about 50 MB.
My question is more of a semantic one concerning the Windows Installed
SDK Help.
I do not see the Small Update being a limitation in the number of
files being updated.
Am I correct?
FYI:
It saves us a lot of time to do Small Updates and not Minor Upgrades.
We try to not change the product code if we can.
Thanks in advance for your help.
Regards,
Dominique G. Schneider
Please don't send me direct emails, use the newsroom or go to
http://contactez.net/portfolio.html
Christopher Painter
Minor Upgrades and SmallUpgrades are practically the same thing... the
difference is symantec in that the ProductVersion changes during a
Minor Upgrade and it doesn't for a Small Upgrade.
Also all of the various upgrades can be serviced as either a patch or
a full package.
Adrian Accinelli
news:1b96aea8-d01e-4912...@t54g2000hsg.googlegroups.com...
Exactly.
Prior to Windows Installer v3, I only created Small Update patches and like
you they became neither small nor simple beasts. Once v3 came along with
patch sequencing available I found the only way to get proper sequencing of
hotfixes and service packs was to ensure that the service packs were built
as minor upgrades and hotfixes were built as small updates.
If you don't change the ProductVersion value then it becomes increasingly
difficult (likely impossible eventually) to supersede all the previous
patches you have released [note: I'm talking about proper supersedence model
here rather than obsolescence]. However if you make your patches minor
upgrades (aka Service Packs) then you can move from one patch to the next
knowing full well that changes in earlier MSPs will be superseded correctly.
Hotfixes can then be sequenced in between and you end up with a very
flexible solution (albeit more complicated that just doing pumping out major
upgrade packages).
Sincerely,
Adrian Accinelli
DGSchneider
Thank you!
We do agree, and you both confirmed my findings - we do not change the
Product Version to make it a Small Update.
I guess I was puzzled by the sentence "A small update makes changes to
one or more application files that are too minor to warrant changing
the product code." Of the online help.
The Small Update way allows us to always target the same (released)
version.
Our Small Updates being all accumulative, it is one of the reasons why
they get so big; but once they reach their maximum size they do not
get bigger (average 50MB).
As far as I could test, using Minor Upgrades means changing one of the
6 first digits of the product version (the first 3 sets of 2 in the
following example).
If we do so we need to target all the Minor Upgrades updated versions
(For example release 01.00.00.00 - 01.00.01.00 is a Minor Upgrade that
targets 01.00.00.00 - Minor Upgrade 01.00.02.00 must target
01.00.00.00 and 01.00.01.00 - Minor Upgrade 01.00.02.00 must target
01.00.00.00 and 01.00.01.00 and 01.00.02.00 and so on...).
We may do over 15 Small Updates before we release again. Considering
that we release over 3000 files per product, and we have over 35
products in about 9 languages... it becomes you know what...
By using Accumulative Small Updates and knowing we always target the
released version (01.00.00.00 in my example) we never found a problem
using Small Updates. (because our small updates are accumulative we
can supersede the previous ones.)
Your statement "Once v3 came along with patch sequencing available I
found the only way to get proper sequencing of hotfixes and service
packs was to ensure that the service packs were built as minor
upgrades and hotfixes were built as small updates." is very
interesting.
I would like you to elaborate on the statement "Also all of the
various upgrades can be serviced as either a patch or a full package."
Can you give me more details on this so I can better visualize this
logic and if we can apply it in our case? Thanks...
Adrian Accinelli
news:bd3c5f7b-4f92-4396...@u69g2000hse.googlegroups.com...
<snip>
> Thank you!
> As far as I could test, using Minor Upgrades means changing one of the
> 6 first digits of the product version (the first 3 sets of 2 in the
> following example).
In MSI version terms you only have 3 digits Major.Minor.Build (use of a
fourth is optional and ignored in upgrade comparisons). As long as one of
these version fields change then you have yourself a minor upgrade.
In [1] you can find the statement "Changing the product version of the
application means that the different updates have an order." This is key
because without proper version changing you lose the entirety of patch
targeting benefits.
> If we do so we need to target all the Minor Upgrades updated versions
> (For example release 01.00.00.00 - 01.00.01.00 is a Minor Upgrade that
> targets 01.00.00.00 - Minor Upgrade 01.00.02.00 must target
> 01.00.00.00 and 01.00.01.00 - Minor Upgrade 01.00.02.00 must target
> 01.00.00.00 and 01.00.01.00 and 01.00.02.00 and so on...).
> We may do over 15 Small Updates before we release again. Considering
> that we release over 3000 files per product, and we have over 35
> products in about 9 languages... it becomes you know what...
> By using Accumulative Small Updates and knowing we always target the
> released version (01.00.00.00 in my example) we never found a problem
> using Small Updates. (because our small updates are accumulative we
> can supersede the previous ones.)
There's a tremendous difference between small and minor. You think you are
superseding now but in fact you are not. Carefully read over [3] and
realise that for small updates supersedence flag is ignored. What is really
happening is that as you add more and more small updates together your
patches all get marked as "applicable" and the installer intelligently
merges the file differences (taking the highest versioned change in each
case). You are not performing any MST operations that would conflict with
each other so everything works for you.
When you use minor upgrades supersedence really comes into play and you will
have all the patch changes essentially removed from play after the patch
sequencing finishes. This is key for being able to fix screwed up MSI
tables (say from a bad MSP?).
I agree that with so many files and products + languages you get into
complicated situation with creation of the fully targeted MSPs. What the a
fully targeting aware minor upgrade MSP allows you to do is to properly
upgrade to any combinations of MSI image states. For example the RTM admin
image, the admin image with a previous MSP applied directly to it, and of
course RTM installed locally with any previous MSP applied are all different
situations where minor upgrade patch will target/apply correctly.
Essentially it is the swiss army knife of patches - most flexibility but a
bit hard to cram everything into the final package.
> Your statement "Once v3 came along with patch sequencing available I
> found the only way to get proper sequencing of hotfixes and service
> packs was to ensure that the service packs were built as minor
> upgrades and hotfixes were built as small updates." is very
> interesting.
Try one minor upgrade using MSP for yourself and look at your verbose log
file and you will see the truth of my statement.
> I would like you to elaborate on the statement "Also all of the
> various upgrades can be serviced as either a patch or a full package."
> Can you give me more details on this so I can better visualize this
> logic and if we can apply it in our case? Thanks...
This remark was from Christopher but each UpgradedMSI image you create for
purposes of creating an MSP could be used in its entirety to perform an
upgrade from an existing version. That said I wouldn't suggest it for
small/minor upgrades because you lose all the flexibility of the MSP patch
sequencing model.
A full statement of this is in description field of the table describing
each upgrade type located at [3].
----
References:
[1] Minor Upgrades
http://msdn2.microsoft.com/en-us/library/aa370037(VS.85).aspx
[2] Generating Patch Sequence Information (PATCHWIZ.DLL)
http://msdn2.microsoft.com/en-us/library/aa368623(VS.85).aspx
[3] Patching and Upgrades
http://msdn2.microsoft.com/en-us/library/aa370579(VS.85).aspx
Sincerely,
Adrian Accinelli