Mvvmcross: Move back sub repos into main

[Cheesebaron]

To have a much less complex build process we would need to merge back in the sub repos into the main repo. This is due to now the build process would look something like this:

1. Build main repo
2. Create nuget packages
3. For each of the other repositories:
   a. Restore Nuget Packages
   b. Update Nuget Pacakges
   c. Build repo
   d. Create Nuget Packages
   e. Commit Nuget changes done in b.

Especially the 3.e. would be very problematic. I.e. how do you determine that 3.b. was successful. It is not unseen that NuGet Updates go wrong.

Instead it would be much easier to just have step 1. and 2., nothing more. This requires everything is in the same repository.

So the suggestion is to move, Plugins, AndroidSupport, iOSSupport and Forms back into MvvmCross.

[kjeremy]

I'm torn on this. I agree that it makes builds easier and it will be much more efficient to hack on things like the android support packages but there's something... sucky about having so many projects in the same repo.

An alternative would be to have a repo of submodules that we use for the build but I don't see why we would want that over your proposed solution.

[kjeremy]

I suppose another alternative would be to have a stable interface between MvvmCross and the rest of the repos.

[heytherewill]

@kjeremy I think using submodules is better than merging back into main because it keeps the repositories apart; I don't need to download MvvmCross if I just want to change something in a Plugin, for example.

Isn't it why this repo exists?

[kjeremy]

@willsb yes I believe that was the original purpose.

I agree on your plugin example though we would ultimately need a commit to bump the submodule in the main repo when it comes time for a release of the plugin. Ultimately I think that's one downside we may face: one offs will be hard (though maybe that's not a big deal).

[ghuntley]

I highly/strongly recommend merging back to a single repository. Happy to jump on a video chat with the core team and share some notes/thoughts about the journey RxUI went through to achieve one button releases via the GitHub pullrequest UI.

Treat mvvmcross for what it is. Ruby on Rails. A single commit to plugins or anywhere should yield a new release. That release should constrain all dependencies or nuget packages to that particular version that was built. This will make your life as an open source maintainer so much better. Now a release doesn't have to be released on nuget. ResctiveUI uses gitflow without support branches. Just develop and master. When a commit lands on develop that's a new release to myget. Every now and then the core group decides to do a pull request from develop to master and that tags the repo and triggers a release to nuget.

If the decision is made to keep everything as separate repos then I suppose you could hack something by adjusting the bootstrap to clone all repos and any commit in any upstream repo triggers build of everything but then you won't be able to implement an automatic release strategy without alot of pain in implementation and ongoing maintenance

Easy path:

1) Move back to single repo.
2) Steal RxUI infrastructure for CI
3) implement policy about merge and rebase commits.
4) implement policy about commit message standards.
5) implement GitHub issue templates.
6) create GitHub reviewer teams in your organisation, one per platform and delegate reviews to them.
7) create appropriate GitHub labels, one per platform and one for core.
8) update nuspec to pin to build version for all nuget packages
9) done.

You'll have automatic and painless releases with zero ongoing maintenance overheads.

[Cheesebaron]

It has been done!

Now we need to create a bunch of labels for issues and nuke the old repos or redirect them somehow.