AllowDowngrades="yes" warning LGHT1076 : ICE61

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

AllowDowngrades="yes" warning LGHT1076 : ICE61

Alain Forget
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: AllowDowngrades="yes" warning LGHT1076 : ICE61

Phil Wilson-2
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:[hidden email]]
Sent: Saturday, April 13, 2013 1:54 PM
To: [hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: AllowDowngrades="yes" warning LGHT1076 : ICE61

Alain Forget
In reply to this post by Alain Forget
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:[hidden email]]
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:[hidden email]]
Sent: Saturday, April 13, 2013 1:54 PM
To: [hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: AllowDowngrades="yes" warning LGHT1076 : ICE61

robmen
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 <[hidden email]> 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:[hidden email]]
> 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:[hidden email]]
> Sent: Saturday, April 13, 2013 1:54 PM
> To: [hidden email]
> 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
> [hidden email]
> 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
> [hidden email]
> 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
> [hidden email]
> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: AllowDowngrades="yes" warning LGHT1076 : ICE61

Wyrdfish
I think that using downgrades to support a rollback scenario is slightly
dangerous in that the user may not realize that they are putting an earlier
version on as it just gets on with it.

Most people block downgrades and let their users un-install and re-install an
older version or have any patch be un-installable to support downgrades. It's
also an extra set of scenarios to test. Do you run any upgrade configuration
that would need to be reversed? If so would you know in advance when you
release your old installer how to reverse it bearing in mind your future
version has not been written yet?

Also balance the support costs of people downgrading by accident and
contacting support against the slight pain of having to uninstall by hand to
install an older version.


-----Original Message-----
From: Rob Mensching [mailto:[hidden email]]
Sent: 15 April 2013 16:55
To: [hidden email]; 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 <[hidden email]> 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:[hidden email]]
> 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:[hidden email]]
> Sent: Saturday, April 13, 2013 1:54 PM
> To: [hidden email]
> 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
> [hidden email]
> 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
> [hidden email]
> 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
> [hidden email]
> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: AllowDowngrades="yes" warning LGHT1076 : ICE61

Alain Forget
In reply to this post by robmen
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:[hidden email]]
Sent: April 15, 2013 11:55
To: [hidden email]; 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 <[hidden email]> 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:[hidden email]]
        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:[hidden email]]
        Sent: Saturday, April 13, 2013 1:54 PM
        To: [hidden email]
        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
        [hidden email]
        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
        [hidden email]
        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
        [hidden email]
        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
        [hidden email]
        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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: AllowDowngrades="yes" warning LGHT1076 : ICE61

Phil Wilson-2
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:[hidden email]]
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:[hidden email]]
Sent: April 15, 2013 11:55
To: [hidden email]; 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 <[hidden email]> 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:[hidden email]]
        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:[hidden email]]
        Sent: Saturday, April 13, 2013 1:54 PM
        To: [hidden email]
        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
        [hidden email]
        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
        [hidden email]
        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
        [hidden email]
        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
        [hidden email]
        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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: AllowDowngrades="yes" warning LGHT1076 : ICE61

Alain Forget
In reply to this post by Wyrdfish
Our software runs in the background with little to no user interaction. When users go to install our software, we will direct them
to a page that will immediately serve the current version, so I don't think users even could install an older version. Even if they
did, when the software talks to our server, it'll have to update right away (and won't work until the update is complete). Any
upgrading (or downgrading) happens automatically in the background, without any user interaction (aside from a prompt for admin
privileges and maybe a prompt information them of the upgrade). In fact, one of the primary goals is to minimise user interaction.

-----Original Message-----
From: David Watson [mailto:[hidden email]]
Sent: April 15, 2013 12:14
To: General discussion for Windows Installer XML toolset.; [hidden email]
Subject: RE: [WiX-users] AllowDowngrades="yes" warning LGHT1076 : ICE61

I think that using downgrades to support a rollback scenario is slightly dangerous in that the user may not realize that they are
putting an earlier version on as it just gets on with it.

Most people block downgrades and let their users un-install and re-install an older version or have any patch be un-installable to
support downgrades. It's also an extra set of scenarios to test. Do you run any upgrade configuration that would need to be
reversed? If so would you know in advance when you release your old installer how to reverse it bearing in mind your future version
has not been written yet?

Also balance the support costs of people downgrading by accident and contacting support against the slight pain of having to
uninstall by hand to install an older version.


-----Original Message-----
From: Rob Mensching [mailto:[hidden email]]
Sent: 15 April 2013 16:55
To: [hidden email]; 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 <[hidden email]> 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:[hidden email]]
> 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:[hidden email]]
> Sent: Saturday, April 13, 2013 1:54 PM
> To: [hidden email]
> 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
> [hidden email]
> 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
> [hidden email]
> 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
> [hidden email]
> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any
of its contents, and we further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: AllowDowngrades="yes" warning LGHT1076 : ICE61

Alain Forget
In reply to this post by Alain Forget
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:[hidden email]]
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:[hidden email]]
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:[hidden email]]
Sent: April 15, 2013 11:55
To: [hidden email]; 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 <[hidden email]> 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:[hidden email]]
        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:[hidden email]]
        Sent: Saturday, April 13, 2013 1:54 PM
        To: [hidden email]
        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
        [hidden email]
        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
        [hidden email]
        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
        [hidden email]
        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
        [hidden email]
        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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users