major upgrade Vs minor or patch
marioc
The windows installer documentation gives a nice explanatory table of what
the differences are between the three types of updates. (product code &
version changes).
I have also found information on when you must change the product code.
But what I want to know is: Why shouldn't every patch be a major upgrade?
It gives you the freedom of removing components and adding files to
components.
Is there a reason why I shouldn't always use a major upgrade?
As far as I know, the patch file can also be a small msp file and applied
the same way as any other update.
I ask this, because I'll have to remove components (and replace them with
new ones, with complete new content) with most future releases of the
product. I do not want to keep all those unnecessary files/components in my
package.
Any explanation or reference would be greatly appreciated.
Thanks,
Mario
Carolyn Napier [MS]
an update. Product updates, like hotfixes, are generally a fix to a couple
of files included in the product. In fact, I typically relate small updates
to hotfixes / quick-fix engineering (QFE) updates; minor updates to Service
Packs, and major updates to brand new products.
If you take Microsoft Office as an example, the majority of patches they
release are small updates. For Microsoft Word bug fixes, it's simply an
update to winword.exe. There's absolutely no need to create a major update
when the only thing changing is a single file. The Service Packs that
Office releases are minor updates in that they change the ProductVersion of
the Office product. The Service Pack consumes almost all previously
released QFEs so that it's packaged in one single release. (Additionally,
you'll note that the Office Service Packs tend to obsolete a number of
patches -- for this very reason. The service pack contains the fix
already). Again though, Office service packs are updates to some files with
the possibility of an additional feature and component for some new content.
I suppose from my standpoint I'd be curious to know why you are
re-componentizing every release. For example, why are you removing a file
from the product? Why are you constantly adding new content? (Note that
you should be aware of the component authoring rules when adding files to
existing components; especially shared components.)
The purpose of small and minor updates was to allow for easy distribution of
updates to existing files in the product. You can also add new content in a
small and minor update. However, when you start to change the
feature-component mapping or component organization, you will have to use a
major update.
Hope this helps,
- Carolyn Napier [MS]
Microsoft Windows Installer Team
Check out the Windows Installer FAQ at:
<http://www.microsoft.com/windows2000/community/centers/management/msi_faq.a
sp>
Please do not send email directly to the alias used to post to the
newsgroup. The alias is for newsgroup purposes only. This posting is
provided "AS IS" with no warranties, and confers no rights.
"marioc" <mario...@quadrat.be> wrote in message
news:#ka9GnWkCHA.2204@tkmsftngp08...
marioc
To answer your question:
In fact I'd have to remove components, because of the help files for our
application suite.
Till now, all help files were CHM files. For every language and every
application, there was a component with the chm's.
Now, the chm's are being replaced by an html help system. As this is a lot
of work (creation and translation), with every release some CHM's will have
been replaced with the up-to-date html's. That's the reason for the
creation and removal of components.
You say that a major upgrade would be overkill for distribution. In what
way? You only distribute an msp with the file changes as far as I know.
A related patching strategy question:
In the case of MS Office, imagine:
1) There is an official release.
2) Then there is an update to winword.exe. A patch is distributed.
3) Some time later, there's an update for excel.exe. You need a new patch.
I suppose this 2nd patch can be applied to the official release as well as
to a patched installation? Or not?
If it should be applied to the base release, at creation time of the
patch, it will add excel, as well as winword.
If it's a prerequisite to apply it to the 1st patched version, it'll
only include excel.
So the point is: in the first case, your patch will keep on growing and
growing.
In the second case, you have to install a whole bunch of patches, even
though, for example you do not have winword.exe installed.
Basically the question is...
Small updates, are they always based on the first releases? Or is every
patch based on the previous patched version? Or are they based on all
previous patched versions (so they'll patch any (patched) installation)?
Are small patched versions also distributed as full installation products or
is only the base package distributed (with its known shortcommings) and
should the customer apply all patches himself?
Maybe these questions are pretty basic, but there's not much information
with concrete examples on patching available. I think it's quite
complicated. But we are now at the point of a major release, and I would
love to the have patches work throughout the whole application lifecycle.
We'll have a lot of hot fixes and service updates.
Many thanks,
Mario
"Carolyn Napier [MS]" <cna...@online.microsoft.com> wrote in message
news:OepOE$ckCHA.348@tkmsftngp12...
Carolyn Napier [MS]
bit long. This is just forewarning. Your feedback on what is missing in
the documentation is also appreciated. I'll see what I can do about having
more information added to the documentation. As always, specific cases
where you think the documentation should be clarified or examples added are
definitely helpful.
You are correct in that you can distribute an MSP for a major upgrade;
however, major upgrades tend to be more time intensive operations given that
the original product is uninstalled in addition to the new product being
uninstalled. The fact that you are actually performing a full product
upgrade is why I mention that it is overkill. Additionally, depending on
where you sequence RemoveExistingProducts, the application of the major
upgrade patch may require access to the original installation source. This
is a situation that can be generally avoided with small/minor update patches
in Windows Installer version 2.0
Given the situation that you are in which requires new componentization and
the fact that small and minor updates restrict these possibilities, I
understand why you have taken your approach. I wanted to point out that
recomponentization is not always super-common so distribution of updates to
files is much simpler and quicker using small and minor updates.
The MS Office scenario is actually quite different from how you describe it.
I'll try to go over a bit in hopes that it will give you a better picture of
what happens and how the patches are distributed. Note that most of the
information I'm giving will be tailored to Windows Installer version 2.0
support. MSI 2.0 has better support for patches and a number of bug fixes
for patching problems in MSI 1.1. Both can be used for patches and in a
number of cases both work just as effectively. What's important to
understand is that patches need not be cummulative in certain respects. I
would argue that cummulative applies across a single file and across product
versions. What this means is that you can easily author disjoint small
update patches. However, minor update patches should be considered to be
cummulative since you are changing the product version. As for files, each
subsequent patch to a file should include the previous fixes to the file --
otherwise file versions are no longer reliable in determining which file is
newer.
MS Office Scenario:
1) There is an official release of the product
2) A bug is discovered in Word. MS ships a QFE for Word. This QFE updates
the winword.exe file from version 1.0 to version 1.1. The QFE is delivered
as a small update patch. This means that no change is made to the product
code or product version of the product.
3) A bug is discovered in Excel. MS ships a QFE for Excel. This QFE
updates the excel.exe file from version 1.0 to version 1.1. The QFE is
delivered as a small update patch.
Thus far, there is no reason for the QFE for Excel to include anything in
the QFE for Word. They each update a single file but not the same file.
Neither modifies the ProductVersion of the product.
4) A new bug is discovered in Word. MS ships QFE2 for Word. This QFE
updates the winword.exe file to version 1.2. The QFE can patch either
version 1.0 or version 1.1 of the file. The QFE obsoletes the previous
winword QFE. This QFE is delivered as a small update.
Now, we still don't need to include anything from the Excel QFE; however, we
do need to include the previous fix to winword.exe. Patches are cummulative
at the file level so QFE2 includes not only the second fix but also the
first fix. (If we didn't, then file versioning wouldn't work properly).
5) MS decides to release a roll-up patch to Office that includes all
previously released patches. This is the first service release for the
product (SR1). The service release obsoletes all previously released QFEs
and contains all of the fixes (including ones for Excel and Word). The
service release is shipped as a minor update and the product version is
actually updated.
> Small updates, are they always based on the first releases? Or is every
> patch based on the previous patched version? Or are they based on all
> previous patched versions (so they'll patch any (patched) installation)?
Not necessarily. Small updates are generally based upon specific product
versions (i.e. RTM, SP1, SP2, etc.). However, if you use binary patching
(a.k.a. byte-level patching) then you would need to include all previous
combinations of the file to prevent requirement of the original installation
source (even with MSI 2.0). If you use full-file patching, then you don't
get this but you lose the reduced download benefits provided by binary
patching. In general, a binary patch is smaller than the full file. There
are cases where a binary patch won't be smaller and a full file is more
efficient (.chm files come to mind since they are by their nature a
compressed file format).
What actually gets really difficult is dealing with sequencing issues with
small update patches. Minor update patches allow you to enforce sequencing
of the patches through the transform validation flags (correspond to
ProductValidateFlags in the TargetImages table of the PCP file) and the fact
that the ProductVersion is changed. However, small update patches do not
modify the product version so you can't easily enforce a sequence setting.
In this case, it's usually a wrapper (like the ohotfix.exe executable for
Office patches) that handles the proper sequencing of small update patches.
>Are small patched versions also distributed as full installation products
or
> is only the base package distributed (with its known shortcommings) and
> should the customer apply all patches himself?
This decision is left up to the ISV / setup author. If you are dealing with
original equipment manufacturers (OEMs), then you might provide the update
as a slip stream image. Given the volume of QFEs, this isn't usually
performed except at the service pack level though in my experience.
Additionally, use of a slip stream update may be necessitated because of
incorrect authoring of previous patches. The Installer is capable of what
is called implicit obsolescence of patches. Explicit obsolescence of
patches originates from the new patch itself which contains the list of
patch codes to obsolete. This is authored via the PCP file and placed in
the summary information stream of the patch. Implicit obsolescence occurs
when an existing patch's transforms no longer apply to the installation
database on the machine. In this case, the patch is quietly obsoleted.
Obsoletion of a patch means that the patch is unregistered from the
product -- no changes occur to the actual files the patch affects. The
typical scenario for implicit obsolescence is when you mix client patching
with patching of admin images. When the admin image is updated, the client
patches may no longer be necessary and are therefore quietly unregistered.
There's a lot of information here so hopefully I haven't confused you.
Don't hesitate to ask for more clarification if necessary.
Hope this helps,
- Carolyn Napier [MS]
Microsoft Windows Installer Team
Check out the Windows Installer FAQ at:
<http://www.microsoft.com/windows2000/community/centers/management/msi_faq.a
sp>
Please do not send email directly to the alias used to post to the
newsgroup. The alias is for newsgroup purposes only. This posting is
provided "AS IS" with no warranties, and confers no rights.
"marioc" <mario...@quadrat.be> wrote in message
news:O0Ur4rhkCHA.1736@tkmsftngp11...
marioc
to work out how we will try to patch our products.
"Carolyn Napier [MS]" <cna...@online.microsoft.com> wrote in message
news:ucIVJeblCHA.2096@tkmsftngp07...