2. I'm going to break this into a separate thread, hope that's OK.
It looks like Heath's change only added new methods. Bob says that this is
breaking because 3.7's changes were breaking. Let's look back at the
changes made to IBootstrapperApplication between 3.6 and 3.7:
1. Added new bootstrapper relation type (BOOTSTRAPPER_RELATION_UPDATE).
2. Added new BOOL member to BOOTSTRAPPER_COMMAND struct (fPassthrough).
3. Added new int parameter to OnSystemShutdown (nRecommendation).
4. Added new BOOL parameter to OnDetectBegin (fInstalled).
5. Added new method: OnDetectForwardCompatibleBundle.
6. Added new method: OnDetectUpdateBegin.
7. Added new method: OnDetectUpdateComplete.
8. Added new BOOTSTRAPPER_RELATION_TYPE parameter to OnDetectRelatedBundle.
3, 4, and 8 are clearly breaking since they added required parameters to
existing methods. I'm not a COM expert, but because we force a recompile
and are not striving for binary compatibility, I don't believe adding
methods is a breaking change.
I think we need to give ourselves the ability to add methods to
IBootstrapperApplication. Full disclosure: I've been thinking about
somehow informing the BA when creating a system restore point, which I'm
pretty sure will require some new methods.
On Sun, Apr 27, 2014 at 11:50 PM, Bob Arnson <b...@joyofsetup.com> wrote:
> Links:
>
> 1. https://github.com/wixtoolset/wix3/pull/21/files#r12034827
> 2. https://github.com/wixtoolset/wix3/pull/15/files#r12034610
>
> On 28-Apr-14 00:49, Bob Arnson wrote:
> > Not the kind of style discussion that devolves, I hope.
> >
> > 1. Sean sent a pull request that added an option to force packages to
> > be cached by specifying an AlwaysCache attribute (yes/no) on the
> > package. Caching is already controlled by a Cache attribute (yes/no).
> > Sean gets bonus internet points for throwing a message if you were to
> > specify both attributes. But the need to do that indicates a schema
> > smell: Having two attributes to control three states is a bit wonky.
> > One option is to create a new enum type to specify the three states.
> > (This is done elsewhere in WiX, yielding perhaps my favorite boolean
> > type: YesNoButton.) The downside is that while authoring would be
> > compatible, there's a slight non-zero chance that someone could have a
> > CodeDOM or similar dependency on the original type.
> >
> > Should we stick with the two attributes in v3.x and clean it up in v4.0?
> >
> > 2. Heath sent a pull request that, among other things, adds two
> > methods to IBootstrapperApplication. Last time, we decided on a
> > "no-error recompile required" policy. Heath suggested versioned
> > interfaces. I'd be OK with that, as long as we don't carry them over
> > to v4.0.
> >
> > Objections/concerns?
> >
> >
> > --
> > sig://boB
> > http://joyofsetup.com/
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> WiX-devs mailing list
> WiX-devs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
