Move Git Version plugin to MinecraftForge/GitVersion

[Jonathing]

For now, the Git Version plugin used by GradleUtils is stored in this repo. By the time I roll around to making GU 3.0, I will be moving this plugin to the GitVersion repo and it will be published from there. Here will be the key differences:

• net.minecraftforge:gitversion -> net.minecraftforge:git-version
• 2.4.x -> whatever version Git Version itself is on

The other option would be to keep the current values and start the Gradle plugin from version 3 when it is moved. Either way, GU will still depend on it specifically for the Changelog plugin. Open to comments, suggestions, and complaints.

[PaintNinja]

Alright, a couple of things... feeling a bit moody today so please forgive my wording.

1. I don't think you should change the artifact name to include a dash and have the naming be inconsistent. It seems unnecessarily confusing to move new versions to the same name but with a dash in it except the repo has no dash but the plugin name has a space instead of a dash. Keep it consistent - call it GitVersion, call the repo name GitVersion, call the maven artifact gitversion (same but all lowercase to match Maven convention), done.
2. The same complaint I have with "java version" and "groovy dsl improver" - they both sound like they do completely different things to what they actually do. I hear "java version" or "git version" and the first thing I think of is the --version arg and wonder why we're making bloated Java wrappers around something so simple. "groovy dsl improver" is in the same camp - it makes me thing it's something to do with Groovy DSLs, but actually it's specific to Gradle only. Surely we can come up with better names... "JavaGrabber", "GitAwareVersioning", I don't know exactly but you get the idea.

[Jonathing]

I don't think you should change the artifact name to include a dash and have the naming be inconsistent. [...] Keep it consistent - call it GitVersion, call the repo name GitVersion, call the maven artifact gitversion (same but all lowercase to match Maven convention), done.

Big man says he has no preference. I only bring it up because I would like to keep all releases of a project under a single namespace. Since Git Version is still in 0.x, then that can be arranged. But I hope you don't change your mind later because I don't want to have another GradleUtils moment where there are three entries of it in the project index.

I hear "java version" or "git version" and the first thing I think of is the --version arg and wonder why we're making bloated Java wrappers around something so simple. [...] Surely we can come up with better names... "JavaGrabber", "GitAwareVersioning", I don't know exactly but you get the idea.

I do not enjoy having this conversation because every time we have it it ends up going completely fucking nowhere. So I'll share my two cents on project names so that we can at least have this discussion 10 times less.

I do not care about the precise naming of projects. If I did, then I'd have already requested to have all of our projects renamed. Likewise, I also do not want project names to become bloated and long, as it becomes counterintuitive when referencing them, especially when we have so many projects that are very important to the chain of command. This is like if I asked "why do we call it MCPConfig even though it has nothing to do with MCP mappings?" A project's name does not need to be declaritive of what the project is doing, or else Forge would just be an acronym for "Fucking Operates the Running Game Engine". The only thing that really matters about a project name is that if it is referenced in discussion, we know what we are talking about. A vast, vast majority of Forge projects are never even shown to the player playing Minecraft.

So truthfully, respectfully, and with awareness to the existing project bloat we have, I think this conversation has proven to be a waste of time. Even if there is merit around changing project names, the question is always "what if we changed the name" and not "can we please change the name". If you want to see project names changed, it'd better if we had a concrete list of projects, why their names are bad, what the changed name could be, and what we'd need to do to apply it. Because it is much more productive for me to change the name of a project and the artifact rather than be annoyed that it's brought up every week without any clear conclusion.

[Jonathing]

I'm still undecided on how I want to tackle this. I think that the idea that I've been flirting with the most is to have MinecraftForge/GitVersion include the Git Version API/CLI tool along with both the gitversion and changelog plugins, since all three of those things are effectively just Git Version used in slightly different ways. It would give GradleUtils its own identity as the lightweight, inoffensive Gradle plugin that just provides some additional functionality and utility methods without actually doing much.

On top of this, I think that the Git Version CLI tool will have its artifact name changed to net.minecraftforge:gitversion to have parity with the Gradle plugin. Still undecided if the version of the tool should match the version of the Gradle plugin, but if they will, then the tool's first major release will be 3.0 instead of 1.0.