[wix-devs] Monorepo with integrated segments - api/burn

[Sean Hall]

>  I thought so but then it looked like the interfaces/base classes were
the primary way used to communicate with Burn.

It sounds like the message based API comparison to the COM interfaces API
definitely needs to be a meeting discussion topic.

On Thu, Apr 29, 2021 at 10:59 AM Rob Mensching <rob at firegiant.com> wrote:

> > This was the whole point of moving to the message based API.
>
> I thought so but then it looked like the interfaces/base classes were the
> primary way used to communicate with Burn. This is one of the areas I
> expect needs more refinement.
>
> > Putting the message API headers with balutil/bextutil is not helping at
> all with revving infrequently, but it is a major productivity hit when
> working on Burn.
>
> I still plan to add the ability to direct reference pieces to fix any
> developer productivity hits. I had it kinda'/sorta' working in micro-repos
> but it will be easier in the mono-repo with fixed locations for everything.
> So we should be able to get APIs revving at a slower pace than the engine
> as appropriate (namely, there can be pure bug fixes in the engine without
> revving the API).
>
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
> Hall via wix-devs
> Sent: Wednesday, April 28, 2021 12:00 PM
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: Re: [wix-devs] Monorepo with integrated segments - api/burn
>
> >  The only mitigation I have right now is that 1. the interfaces can't
> change much and 2. (hopefully) balutil/bextutil code won't change much
> after release. #2 is purely a guess based on how much change there was in
> WiX v3.
>
> This was the whole point of moving to the message based API. There were
> very few changes in v3 because doing so was a breaking change. With the new
> message based API, I expect more changes.
>
> Putting the message API headers with balutil/bextutil is not helping at
> all with revving infrequently, but it is a major productivity hit when
> working on Burn.
>
> On Wed, Apr 28, 2021 at 1:56 PM Rob Mensching <rob at firegiant.com> wrote:
>
> > > But there's a key difference - the base implementations in
> > > Extensibility
> > are intended to be minimal so they shouldn't change while the base
> > implementations in api/burn are not minimal and may receive feature
> > enhancements in the future.
> >
> > This is 100% correct.
> >
> > > This seems to conflict with the goal of API packages revving
> > infrequently.
> >
> > Also, correct. The only mitigation I have right now is that 1. the
> > interfaces can't change much and 2. (hopefully) balutil/bextutil code
> > won't change much after release. #2 is purely a guess based on how
> > much change there was in WiX v3.
> >
> > I do expect we will learn a few more things once this integration is
> > complete and will adjust post-preview.0. The key factor is I believe
> > this overall structure will allow us to meet all of our goals (where
> > the current micro-repos were not).
> >
> >
> > -----Original Message-----
> > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of
> > Sean Hall via wix-devs
> > Sent: Wednesday, April 28, 2021 7:40 AM
> > To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> > Cc: Sean Hall <r.sean.hall at gmail.com>
> > Subject: [wix-devs] Monorepo with integrated segments - api/burn
> >
> > Under api/burn, there are three separate concerns. Roughly speaking,
> > WixToolset.BootstrapperCore.Native is analogous to WixToolset.Data (1).
> > Changes there will require changes to both Burn (WixToolset.Core) and
> > the rest of api/burn (WixToolset.Extensibility).
> >
> > balutil, bextutil, and WixToolset.Mba.Core/mbanative are analogous to
> > WixToolset.Extensibility. All of those have both interfaces (2) and
> > base implementations (3). But there's a key difference - the base
> > implementations in Extensibility are intended to be minimal so they
> > shouldn't change while the base implementations in api/burn are not
> > minimal and may receive feature enhancements in the future. This seems
> > to conflict with the goal of API packages revving infrequently.
> >
> > On Wed, Apr 28, 2021 at 2:11 AM Rob Mensching
> > <notifications at github.com>
> > wrote:
> >
> > > ------------------------------
> > > You can view, comment on, or merge this pull request online at:
> > >
> > >   https://github.com/wixtoolset/UnifiedTest1/pull/5
> > >
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> > http://www.firegiant.com/
> >
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>