Hmm, you've all made some excellent points. I'm definitely glad I asked for input. I'm sufficiently convinced that allowing downgrades is more of a complication than it's worth, so I'm going to return to disallowing downgrades. Thanks again for the insightful discussion!
Alain -----Original Message----- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: April 15, 2013 13:18 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] AllowDowngrades="yes" warning LGHT1076 : ICE61 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 ------------------------------------------------------------------------------ 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
