Re-consolidate or leave separate?

[Ryan Riley]

After first consolidating everything in one repo, we then decided to separate all the little projects into their own repositories on GitHub. Was that the right move? Should we re-consolidate?

I'm about to start updating some builds for projects I'm still maintaining to use FAKE and Paket, as also favored by Chris. Thoughts on this? How do we extend these changes to other repos? Most use the WebAPIContrib project as their origin, so it may be possible to simply cherry-pick the commit(s) to change the build. I'll experiment on WebApiContrib.Formatting.Html and WebApiContrib.Formatting.Razor. I would still be interested in thoughts.

Cheers,
Ryan

[Filip W]

Normally I am not a fan of dumping everything organization related into a single repo, but I can see the value here.

Perhaps a good idea would be to switch to a single solution with a bunch of projects, each of which can still produce its own Nuget packages. I have used various WebApiContrib components in many many projects and have found the modular approach on Nuget working really good.

The benefit of a single solution would be:

1) much easier Web API version management - as all components would/could be upgraded together, which I think is a big benefit, as it would guarantee compatibility between components, which is now missing

2) better issue management on Github, as they are now scattered all over the place (somewhat of a Github deficiency too)

Another thing mentioned a couple times has been source-based distribution. For example Massive or TinyIoC do this; this solves lots of problems regarding the DLL hell and dependency management, as well as allows users to easily tweak whatever needs to be tweaked. I would suggest this being the default mode, just include the source file in the Nuget package.

cheers & Happy New Year!

Filip

--
You received this message because you are subscribed to the Google Groups "WebApiContrib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webapicontri...@googlegroups.com.
To post to this group, send email to webapi...@googlegroups.com.
Visit this group at http://groups.google.com/group/webapicontrib.
For more options, visit https://groups.google.com/d/optout.

[Ryan Riley]

On Wednesday, December 31, 2014 2:11:40 AM UTC-6, Filip W wrote:

Normally I am not a fan of dumping everything organization related into a single repo, but I can see the value here.

Perhaps a good idea would be to switch to a single solution with a bunch of projects, each of which can still produce its own Nuget packages. I have used various WebApiContrib components in many many projects and have found the modular approach on Nuget working really good.

Yes, this is exactly what I would propose, as well. A previous NuGet packaging concern was my unfamiliarity with PSake as a build tool. Since Chris and I (and I think Filip, too) all like FAKE and Paket, we will likely switch to that. I'm happy to make the conversion and maintain the builds, as well as move that all to AppVeyor, if that works for everyone.
 

The benefit of a single solution would be:

1) much easier Web API version management - as all components would/could be upgraded together, which I think is a big benefit, as it would guarantee compatibility between components, which is now missing

2) better issue management on Github, as they are now scattered all over the place (somewhat of a Github deficiency too)

Yes, these are indeed excellent benefits! When we elected to split the projects, the idea was that we would have individual contributors for each of those projects. That never really happened, and it caused the few of us maintaining the projects a lot of work anytime we needed to make a few tweaks to the build, dependencies, etc. I don't think we can or should merge all projects back together. For example, the XlsxFormatter and CollectionJson projects do have active, excellent maintainers. It's the rest of the projects that were originally together and could easily be merged back together that I propose we merge. I'll work on that and submit a PR for review.
 

Another thing mentioned a couple times has been source-based distribution. For example Massive or TinyIoC do this; this solves lots of problems regarding the DLL hell and dependency management, as well as allows users to easily tweak whatever needs to be tweaked. I would suggest this being the default mode, just include the source file in the Nuget package.

cheers & Happy New Year!

A very happy New Year to you all!

Ryan

[Ryan Riley]

With respect to allowing source downloads, keep in mind that NuGet 3.0 is going to do away with Content (so I've heard). Should we instead focus on something like the Paket GitHub references? This would mean we should optimize for single-file downloads, I think. Most projects already have only a single file with the exceptions of WebAPIContrib and WebApiContrib.Formatting.Razor (and possibly .Html). WebAPIContrib is just a collection of things, though, so the idea that they need to be moved to a single file is a little silly. What about .Razor and .Html? Could those be merged into a single file? It's possible we could do that as part of the build, but I don't think the files are all that large. Thoughts?

[Chris Missal]

I'm watching from the sidelines at the moment, sorry I can't be more involved, but what I'm seeing looks great so far. I'm totally cool with the change in approach fwiw.

On Wed, Dec 31, 2014 at 11:37 AM, Ryan Riley <ryan....@panesofglass.org> wrote:

With respect to allowing source downloads, keep in mind that NuGet 3.0 is going to do away with Content (so I've heard). Should we instead focus on something like the Paket GitHub references? This would mean we should optimize for single-file downloads, I think. Most projects already have only a single file with the exceptions of WebAPIContrib and WebApiContrib.Formatting.Razor (and possibly .Html). WebAPIContrib is just a collection of things, though, so the idea that they need to be moved to a single file is a little silly. What about .Razor and .Html? Could those be merged into a single file? It's possible we could do that as part of the build, but I don't think the files are all that large. Thoughts?

--

You received this message because you are subscribed to the Google Groups "WebApiContrib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webapicontri...@googlegroups.com.
To post to this group, send email to webapi...@googlegroups.com.
Visit this group at http://groups.google.com/group/webapicontrib.
For more options, visit https://groups.google.com/d/optout.

--

Chris Missal

http://chrismissal.com

[Ryan Riley]

On Wednesday, December 31, 2014 11:40:01 AM UTC-6, Chris Missal wrote:

I'm watching from the sidelines at the moment, sorry I can't be more involved, but what I'm seeing looks great so far. I'm totally cool with the change in approach fwiw.

Care to weigh in on https://github.com/WebApiContrib/WebApiContrib.Formatting.Razor/pull/19 ?

[Ryan Riley]

I just added a test of friendship. ;) If that looks okay to others, I'll do the same for the TemplateBase. TL&DR; I added an F# port as None so that it can be retrieved as a source include.

[Ryan Riley]

Same thing here: https://github.com/WebApiContrib/WebApiContrib.Formatting.Html/pull/5

On Wednesday, December 31, 2014 11:50:18 AM UTC-6, Ryan Riley wrote:

[Ryan Riley]

I've been looking into this further. In short, merging is going to be a real pain since the original approach to splitting all this apart was by copying WebApiContrib and then renaming things. Merging things back together is therefore a perilous exercise in trying to detangle everything.

Ultimately, I realized I don't find the separate repos a problem. The main problem is trying to update all the builds. For that, I think I found a simple solution: git submodules and parameterized FAKE targets. I'm going to take a stab at this and submit a PR.

[Alexander Zeitler]

👍

Am 11.01.2015 um 23:02 schrieb Ryan Riley <ryan....@panesofglass.org>:

I've been looking into this further. In short, merging is going to be a real pain since the original approach to splitting all this apart was by copying WebApiContrib and then renaming things. Merging things back together is therefore a perilous exercise in trying to detangle everything.

Ultimately, I realized I don't find the separate repos a problem. The main problem is trying to update all the builds. For that, I think I found a simple solution: git submodules and parameterized FAKE targets. I'm going to take a stab at this and submit a PR.

--

[Chris Missal]

On Sun, Jan 11, 2015 at 4:04 PM, Alexander Zeitler <alexande...@pdmlab.com> wrote:

--

Chris Missal | Senior Consultant | Headspring

[Ryan Riley]

As much as I would like to get this done, I've had no time and given this lower priority than other OSS work. I rarely use any of WebApiContrib anymore, and I've been thinking that, were I to do this build update, I would likely be passing maintenance of it to whoever is left. I think it is likely a better solution for someone else to tackle this problem, if it's even a real problem. Others seem to like the idea, but I think I'm the only one who really brought it up. Thoughts?