Separate repos

[rosshadden]

I would like to propose the idea of having all of the runtimes in separate repositories. Then users could simply clone or submodule the specific runtimes to their project, and no copying or archive downloading is necessary. And this would have the enormous advantage of letting people update their submodules when you push out an update, rather than repeating the current workflow for using specific runtimes from here.

If you did so, you could even continue to maintain this repo by replacing all of the runtime folders with submodules pointing to them, and people using this repo wouldn't actually have to do anything different (except cloning with the --recursive flag, but that is so common that people using GUIs generally have it done for them).

I would even go so far as to guess that nobody actually "uses" this repo as it is, by which I mean clone or use as a submodule. Everybody probably just downloads it and takes the folders they need, which is a rather outdated workflow for post-2010. Since git does not support partial clones, the current workflow for using this repo is actually pretty bad for people used to more... "modern" ones (I'm not trying to be mean with that word; I am just addressing the elephant in the room).

For example:

Say I want to use spine-love, which requires spine-lua as well. This repo is 121 MB, but spine-lua is only 316 kB, and spine-love is only 40 kB. Obviously I am not going to add the entire spine-runtime repo as a submodule in my project because it's so big, but such a workflow is incredibly ideal in almost every situation. If it were set up like that, I would just have spine-love and spine-lua as submodules, and only be adding 356 kB to my project.

In fact, spine-lua could just be a submodule of spine-love as well, which would completely supersede my recently-opened #757. Then people that clone/download/submodule spine-love would have all dependencies, and no unnecessary files.

Just think about it---I realize this would be a small change in your process. You would of course be able to keep all the folders exactly as you have them right now on your systems, but you would have the additional step of committing to this spine-runtimes project when you commit to their individual repos.

[badlogic]

We've considered submodules before. However, given my (vast) experience with submodules in previous (bigger) projects, I'm not sure entirely I'm in favor of this change.

It does indeed impact our workflow quite a bit:

1. Issue reporting would not happen in a centralized place anymore
2. Compilation and distribution of assets would be a lot more cumbersome
3. Version based branching would have to be done on a lot more repositories instead of the single master repository, making it more likely that errors happen

I do strongly agree that copying sources around is not a good solution. However, as you said in your other issue, users could simply clone the entire repo (130mb isn't a big deal in modern workflows :)), then symlink the folders locally as needed.

We have to think about it. Ultimately it's @NathanSweet 's call.

[NathanSweet]

I can see the pros and cons with both approaches. I personally dislike the overhead of dealing with many repos, especially since we version the runtimes together. 2-3 is OK, but 18+ is just too much. It adds lots of "updated submodule" commit noise and makes dealing with the runtimes as a whole terribly annoying. We could write scripts in an attempt to make it more manageable, but that gets messy. I think we'll stick with the monolithic repo for now.