My general experience is that in case of an issue: 

It's unusual for all customers to be affected, usually a few, sometimes just
one.  It's not difficult to focus a team on the problem and get a detour
followed by a hotfix patch, the more important the customer the higher the
priority. Most companies I've been involved with take this approach. 

When it's completed and a fix is ready and tested and the customer is happy,
it's made available to customers that are actually experiencing that issue.
It's tempting to force all customers to take the patch because "the software
is broken" or "they might get the same issue" but I find that sensible (IMO)
companies don't inflict the cost of every routine fix on every customer. 

In case of a complete failure, you can uninstall the new product and
reinstall the old one to get completely back to the older codebase.
Unfortunately, however you do this, the issue isn't usually the install -
it's things like database compatibility (because the new product changed the
schema) and the application in general with newer data, registry data etc.
Going back is more of a nightmare than you may think, depending on the size
and complexity of the application. 

So IMO it's always better to move up with patches and other spot fixes
rather than throw the whole new product away and go back to the old one. 

Phil 

-----Original Message-----
From: Alain Forget [mailto:afor...@cmu.edu] 
Sent: Monday, April 15, 2013 9:14 AM
To: 'Rob Mensching'; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] AllowDowngrades="yes" warning LGHT1076 : ICE61

I want to allow downgrades in case we push out a new  version that is flawed
in some way, and it's non-trivial to quickly fix and publish a new version.
In this case, I want to be able to quickly rollback to the previous version
that didn't have the flaw.

It occurs to me now that this may be a concern many (most?) software
producers may have? Perhaps we're not approaching it in the correct or
standard way?


-----Original Message-----
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: April 15, 2013 11:55
To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] AllowDowngrades="yes" warning LGHT1076 : ICE61

Yes. Curious why you want to support downgrades? Don't hear that very often.


On Mon, Apr 15, 2013 at 8:51 AM, Alain Forget <afor...@cmu.edu> wrote:


        This is very insightful, thanks! So my MajorUpgrade tag looks like
this:
        
        <MajorUpgrade AllowDowngrades="yes"
Schedule="afterInstallInitialize" />
        
        The WiX manual (
http://wix.sourceforge.net/manual-wix3/major_upgrade.htm ) says that the
Schedule="afterInstallInitialize" puts the
        RemoveExistingProducts before anything is installed. So I think this
is good, safe, and the way we want it, correct?
        
        You also made a very good observation about possible shared
resources. Fortunately, our software isn't installing anything that
        other programs use (at least I can't imagine how that can happen).
        
        Alain
        

        -----Original Message-----
        From: Phil Wilson [mailto:phil.wil...@mvps.org]
        Sent: April 14, 2013 15:52
        To: 'General discussion for Windows Installer XML toolset.'
        Subject: Re: [WiX-users] AllowDowngrades="yes" warning LGHT1076 :
ICE61
        
        If your downgrade is effectively the same as an uninstall of the old
product followed by an install of the new product you should be
        ok, and that depends on early sequencing of RemoveExistingProducts.
        
        If your RemoveExistingProducts is at the end somewhere, the upgrade
is like a merge of the components  (when coomponent guids are
        unchanged), and that's true of what you call a downgrade or an
upgrade. I don't think Windows suspends the file version overwrite
        rules, and so will still apply them. If your old version has files
with version 5.0, and the new one has versions of
        6.0 a downgrade may leave you with the old version product with the
6.0 file versions. That's my recollection anyway, and that's why
        the best downgrade is simply to uninstall the broken new product and
reinstall the old one from the install media that you kept,
        right?
        
        Keep in mind components can be shared - let's say your new product
installed new shared Microsoft components that updated files
        because of file version rules. Uninstalling that new product will
simply decrease the ref count on them and the new versions will
        remain on the system. Reinstalling your older product will also
apply file version rules and those Microsoft files will not be
        replaced with older versions from your older install. That's the
same thing that happens when your REP is at the end. So I think
        that's the issue
        - you can end up with an "older" product with a mishmash of file
versions that were probably never designed or tested to work
        together. Obviously deserves a test and a sanity check to be sure
I'm remembering this correctly.
        
        Phil
        
        
        -----Original Message-----
        From: Alain Forget [mailto:afor...@cmu.edu]
        Sent: Saturday, April 13, 2013 1:54 PM
        To: wix-users@lists.sourceforge.net
        Subject: [WiX-users] AllowDowngrades="yes" warning LGHT1076 : ICE61
        
        
        I've recently added the AllowDowngrades="yes" attribute to my
MajorUpgrade element, which resulted in the following light warning:
        
        warning LGHT1076 : ICE61: This product should remove only older
versions of itself. No Maximum version was detected for the current
        product.
        (WIX_UPGRADE_DETECTED)
        
        In a similar post ( see http://sourceforge.net/p/wix/bugs/2405/ ),
Rob explains that the warning is produced by the Windows
        Installer / ICE team, and that they believe allowing downgrades or
same version upgrades is a bad idea.
        
        The reason I think we need to enable downgrades is if we push a new
major upgrade, but find out there's some critical and
        hard-to-fix flaw we missed, and then want to quickly and easily
rollback to an older version.
        
        So the warning is making me wonder if there's a flaw in my logic.
Your thoughts?
        
        Alain
        
        
        ***************************************
        Alain Forget, Ph.D.
        Postdoctoral Researcher
        CyLab, Carnegie Mellon University
        afor...@cmu.edu
        http://cups.cs.cmu.edu/~aforget/
        ***************************************
        
        
        
        
----------------------------------------------------------------------------
        --
        Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for
        building apps and a phenomenal toolset for data science. Developers
can use our toolset for easy data analysis & visualization. Get
        a free account!
        http://www2.precog.com/precogplatform/slashdotnewsletter
        _______________________________________________
        WiX-users mailing list
        WiX-users@lists.sourceforge.net
        https://lists.sourceforge.net/lists/listinfo/wix-users
        
        
        
        
----------------------------------------------------------------------------
--
        Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for
        building apps and a phenomenal toolset for data science. Developers
can use our toolset for easy data analysis & visualization. Get
        a free account!
        http://www2.precog.com/precogplatform/slashdotnewsletter
        _______________________________________________
        WiX-users mailing list
        WiX-users@lists.sourceforge.net
        https://lists.sourceforge.net/lists/listinfo/wix-users
        
        
        
----------------------------------------------------------------------------
--
        Precog is a next-generation analytics platform capable of advanced
        analytics on semi-structured data. The platform includes APIs for
building
        apps and a phenomenal toolset for data science. Developers can use
        our toolset for easy data analysis & visualization. Get a free
account!
        http://www2.precog.com/precogplatform/slashdotnewsletter
        _______________________________________________
        WiX-users mailing list
        WiX-users@lists.sourceforge.net
        https://lists.sourceforge.net/lists/listinfo/wix-users
        
        




----------------------------------------------------------------------------
--
Precog is a next-generation analytics platform capable of advanced analytics
on semi-structured data. The platform includes APIs for building apps and a
phenomenal toolset for data science. Developers can use our toolset for easy
data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Reply via email to