@Team-RTG/everyone

I propose that we consolidate the 1.9 repo into the Realistic-Terrain-Generation repo, as we've done with the 1.8.9 repo, and make a few minor changes to our branching/development workflow.

Essentially, here's what I'm thinking this repo should look like:

Branches:

1.7.10-master
1.7.10-dev
1.8.9-master
1.8.9-dev
1.9.4-master
1.9.4-dev
1.10-master
1.10-dev
Etc.

This branch structure would allow us to maintain our current master/dev workflow, whilst providing a central location for all of RTG's code.

The dev branches will continue to be used for pull requests and for staging the latest development versions, and the master branches will be frozen after every release for that version.

I know the directory/code structure between 'v1' and 'v2' is radically different, but it really doesn't matter to Git, and it would make my life as project manager easier if everything was in one place, and it would make it easier for users when submitting bug reports, etc, so... unless this setup is going to negatively affect anyone's local development workflow, or if there are any other good reasons to not do it this way, then I think this is the way to go, especially with Mojang & Forge releasing more frequently in the months ahead.

One mod. One repo. Multiple version branches.

Thoughts?

i am kinda torn on this.
first of all that is in theory the way to go, but i prefer the idea of an archive repo for 1.7/1.8, simply because i think a refresh is nice, and this is one of the best chances we will ever have for that.

Also, with the talk we have had recently about having a very small core wrapping system that interacts with forge and minecraft version specific things, so we can use the same code across multiple game versions, except for one distinct package that is specific to a version/api (sponge/bukkit support could be considered this way), we might have to do some restructuring anyway. So i think we should take that discussion first.

I have yet to get into the 2.0 code but my impression is that it's different enough it should be a different repo. The point of having things in the same repo is that git can automatically match up similar code and that's not going to work 1.0 -> 2.0.

we might have to do some restructuring anyway

I'm up for restructuring the code to enable/improve compatibility with other mods/platforms, but I don't see why that would require different repos. Unless you meant a different kind of restructuring?

The point of having things in the same repo is that git can automatically match up similar code and that's not going to work 1.0 -> 2.0

In Git's eyes, a branch is a branch is a branch, regardless of the repo in which that branch lives. It would struggle trying to match up v1 code with v2 code no matter what, but... we'd never be comparing/merging code between v1 and v2, unless we were porting features across (for example, from 1.7.10 -> 1.9.4), but... again, it makes no difference to Git which repo the branches live in.

Unless I'm missing something? (which could very well be the case, which is why I opened up this discussion)

Ok peeps, I'm really keen to get these repos sorted out before we start getting into high gear again, so... I'm going to trial this 'one repo' system and see how it goes. If there are any workflow problems that we can't resolve, then we'll just split out v2 into its own repo again.

I'd like to do all of this tonight, so if you have any un-pushed commits, let me know and I'll hold off for a bit.

When the dust settles, there won't be a 'dev' branch anymore, and there won't even be a 'master' branch. All branches will be prefixed with its respective MC version, so if you want to submit a PR from tomorrow for 1.7.10, you would target the '1.7.10-dev' branch, etc.

After the new repo structure is in place, it might be a good idea to re-fork the repo, just to make sure we're all singing from the same hymn sheet.

It has been done.

🙏 May the old gods and the new gods have mercy on our souls. 🙏