Hi,

While looking around the source I've noticed a general lack of branching and tagging conventions, as well as a couple of allusions (in commit messages) to @WayofTime (perhaps?) not being comfortable with that workflow.

I'd like to help any way I can, and think that a restructuring to follow a clear branching and tagging model which adheres more closely to something like semantic versioning could form the basis of restructuring work to make it easier for the community to make valuable contributions in the form of pull requests. Tagging releases has several other advantages (such as being able to cleanly host binaries on Github for direct download, and tying nicely into hosting binaries on maven central)

The reason that I am creating an Issue first rather than just going ahead and creating a pull request so that you can judge such an idea on its merits is twofold:

• Code structure and layout, whilst often guided by software engineering conventions about best practice, is an inherently personal thing. Any such pull request wouldn't be fixing a bug, and it might be good to hash out the details here beforehand.
• The way Github works does not directly allow me to submit a pull request to create a new branch in this repository. I can fork and create a branch, but when I submit a pull request I have to select an existing branch against which to compare my new branch for commit. To get around this I would have to make my fork and ask @WayofTime to add the fork as a new remote for this repository, whereby you can fetch and merge the new branches (effectively manually performing the process of a pull request). I could provide all commands if necessary :).

The branching/tagging scheme workflow I'm proposing is the following:

1. Work on master as before.
2. Use appropriately named branches to introduce code changes for new features or new versions of minecraft, merging those back into master when complete
3. Tag the releases and pre-releases of BloodMagic according to semantic versioning (e.g. 1.2.1, 1.2.2, ... , 1.3.0-alpha, 1.3.0-beta, 1.3.0-rc1, 1.3.0 etc...).
4. Each time you hit a stable release for a version of Minecraft that you plan to support (e.g. 1.6.4, 1.7.2, 1.7.10) branch from master (calling it something like MC1.7.10 for example).
5. Continue to develop as before, but use the latest Minecraft version branch instead of master.
6. When you plan to work on a version of the mod for a further version of Minecraft, merge your changes back into master from the version branch, and tag the latest commit in the version branch as, for example, 1.3.7+MC1.7.10-FINAL.
7. After that point, by convention, only bug fixes would be committed in the various version branches, and would only receive tags with only the patch number changed (e.g. 1.3.8).

Phew - having just read that back to myself I completely understand if you see this and laugh 😝 . If the above seems like too big a departure from your workflow I'd still be interested to know whether you'd appreciate any restructuring/documentation commits?

Lastly, as an aside, @WayofTime - I just want to say: Thanks for all your work on this brilliant mod! I've just exhausted Blood Magic in a world for the first time (MC version 1.6.4) and I must say I'm totally hooked. Going to have to move on to the newer versions to see whats up...