Split the nunit repository into multiple repositories

[CharliePoole]

Now that 3.0, 3.2 and 3.4 have been released, our APIs are relatively stable. Although some changes may continue to occur, we don't expect them to be frequent. There is now much less need for developers to be working, for example, on framework and engine changes at the same time.

The current repository can be split up in several ways, so we should take this a step at a time. Here's one possible order:

1. Remove the portable agent from this repo.
2. Remove the installer project from this repo.
3. Split the repo into nunit-framework and nunit-engine repositories, retaining the console code in the engine repo. In the future we could consider splitting engine and console, however the console is relatively small so this doesn't give a lot of benefit.

[rprouse]

I assume you mean once 3.4 has been released 😄

[CharliePoole]

Yup... it's in the 3.6 milestone.

[CharliePoole]

One subtask here is to figure out how to handle code that is now used in common between the parts that are being split. We currently use source code in src/Common. For example, there are a number of classes shared between nunitlite and the console runner.

Alternatives...

1. Duplicate the code and live with it.
2. Use GitHub submodules for source-level sharing.
3. Create one or more helper assemblies.

In fact, this could be handled as a separate issue before we split anything.

[oznetmaster]

I would love to comment on this, but have no idea what is involved with 2, which seems like the best option from afar.

[CharliePoole]

I left in 1, because I think we should bear in mind that it's possible, even if annoying. Particularly, if we are left with some small number of things that can't be handled any other way.

There is lots of literature about how submodules cause problems, etc. This is especially so when you allow the including projects to modify the submodule. A change to console might inadvertently break nunitlite, for example. We would need to be disciplined about it.

A separate assembly would work well in some cases, particularly for utilities like the color console. It seems less good for what I call "policy code" like deciding what options are supported by a program.

[CharliePoole]

Using this to try out ZenHub's Epic feature - you will only see the included issues listed if you have ZenHub installed in your browser.

[CharliePoole]

@rprouse One conclusion about Epics: the titles of the included issues need to be short, or at least have their key words at the beginning, because of the two-column listing format.

[rprouse]

@CharliePoole this is the first time I've seen the Epic feature in use. I agree that we should probably keep the titles short, or at least make them identifiable by the first few words. I like the feature though, it could be useful for larger themes like this. 👍