[wix-devs] Breaking out DTF, Dutil, Wcautil and maybe others.

[John Cooper]

1) No.  I think the development velocity can be higher with decoupling.  There will be inevitable synchronization issues, but those can be managed.

2) There should be a 'develop' and a 'next' branch.  'Next' reflects the cutting edge, and 'Develop' reflects the merged stuff that is deemed useable.

3) I'll have to think about Sandcastle.  Non-trivial.

--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise Notification Service
Jack Henry & Associates, Inc.® | Lenexa, KS  66214 | Ext:  431050 |JoCooper at jackhenry.com



-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Rob Mensching
Sent: Friday, July 24, 2015 1:59 PM
To: wix-devs at lists.wixtoolset.org
Subject: [wix-devs] Breaking out DTF, Dutil, Wcautil and maybe others.

The e-mail below is from an external source.  Please do not open attachments or click links from an unknown or suspicious origin.

So, the more I've been thinking about it, the more I'm thinking it'd be a good idea to break out several of the more independent pieces of the WiX toolset into separate repo's in the "wixtoolset" organization. Namely: DTF, dutil, wcautil and (maybe, eventually) WixToolset.Data (and, if that, then maybe extensions) .

I've been watching the ASP.NET vNext guys work in their many repo world and I can see a lot of advantages to doing it that way for pieces that are truly decoupled. Particularly because these pieces can be very useful independent of the WiX toolset as a whole (for example, we use dutil *a lot* at FireGiant).

With that in mind, let's just consider DTF, dutil, and wcautil in v4.x (we're not touching WiX v3.x).

Publishing those projects on their own v4 cadence as NuGet packages should be really simple (they are mostly independent of each other and everything else). The WiX toolset can then take them as binary dependencies. The issues that I'd like input on are the following:


1.       Do you think this is a horrible idea. I'm not worried about the -0, +0 or +1  people. I'm looking for those who are -999999 on the idea. If so, why?


2.       What branch strategy should they use? Today, the wix3 and wix4 splits are awesome. The "develop" branch is where you make changes for the "next minor version" and "master" has the last minor version. We can work on each major release independently with no real confusion as to what code goes where.

I'm not particularly interested in a "dtf4" and later "dtf5" (for example) so we'll have to do major and minor branching within the individual repos. Maybe this is less of an issue if there is really only ever one active branch since the projects are smaller. Lots of implications on backwards compatibility and bug fixes and such to consider here.


3.       We'll need to solve the DTF documentation problem since sandcastle's output is integrated into the WiX toolset website build and all that. So, I'd be interested in ideas people have to solve the doc problem.

So there's a bunch of cannon fodder. Thoughts?

PS: this came up because Heath wants to push along the NuGet publishing of WiX stuff (since I've been completely neutralized with work from many different angles). And we should totally do that... but the NuGet packages of interest are really these 3 packages... so let's consider the split now... again, since I'm more and more convinced it's a good idea (if we can solve #2 and #3 above).

Regards,

  Rob Mensching
_______________________________________________________________
FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/

NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.