Split into smaller components and consider moving to fhaculty organization #25
Description
This project should be split into several smaller components in order to simplify code reuse and avoid having to pull in unrelated files.
This raises a couple of questions though:
Which components should be split?
This is mainly smaller library size vs. lots of libraries
Fine grained splitting might be useful, however splitting classes like Dijkstra to its own library might be confusing. Perhaps keep all shortest path algorithms as "graph-algo-shortestpath"?
For now, we should probably NOT split the whole library, but only those parts where it's useful. (Also refs #24)
At some point in time we will probably need something like a "graph-datastructure" base library.
Preserve history?
Assuming we split the UmlClassDiagram, I suppose we should keep its history in the new repo? What about previous versions / renames? Once it's been moved to a separate repo, the relevant classes should be deleted from this main project (and thus preserve its history both here and in the new repo).
Consensus? Best practice?
Where to move to?
Once we start adding a bunch of libraries, we should consider adding it to a github organization. I've created a "fhaculty" organization mirroring the current namespace. Moving everything is going to incur BC breaks and will likely confuse people, so this is not an immediate option.
BC breaks?
Should not be an issue: New split libraries should be reference via composer.json in this project and paths should be unchanged for the first release. Add entry to CHANGELOG. Besides this library being considered beta, this should not break.
Meta data?
Like said above, each new split library should be referenced in this project's composer.json. Also, each new split library should get its own set of meta files, including:
- composer.json
- Add to packagist
- Unit tests
- Travis config
Any thoughts?