Versioning

[schnapster]

The continued split between v2 and v3 branches keeps causing unnecessary work (see merging of #125), as well as confusion in the chat when talking about where an issue is happening.

I propose a faster moving versioning on the main branch. There is no good reason except vanity (imho) to keep holding off the merge of v3 into the main development branch. We have already discussed how the breaking change prompting the v3 bump could have been avoided (instead of changing the endpoint, adding a new one would have been a backwards compatible possibility), so we can all agree that a major version bump should not be happening in the reasonably forseeable future.

There are two more annoyances related to versioning:
Github tags would be super helpful. Many times ppl get confused by the CI server and use builds from outdated, or non-supported branches. However, due to the LavalinkClient residing in the same repo as the LavalinkServer, we can't version them individually by tags. They don't even use any shared code, so moving the client into it's own repo would be the sane decision.

Here are the proposed milestones for the current features in development / things required to make it work:

2.2:

• Release the outstanding changes on the dev branch Release v2.2 #132

3.0:

• Move client to its own repo (I would ask @Frederikam to consider doing this, but I can also offer setting it up under the FredBoat org) Move the client subproject to its own repo #128
• Generate version from git tag (I would PR this) Infer version from git tag #129
• Release all the current changes that reside on the v3 branch.

Rough roadmap for post 3.0:

3.1, or general 3.x minors, depending on how development goes:

• Replace JDAA with Magma

Majors:

• Java 11
• Add a plugin system #119 Plugin system

[shikhir-arora]

Fred had briefly mentioned the idea in FredBoat #selfhosters of making a central repository for a few FB things, and sensible Lavalink configs. Though not entirely on topic that seems like a fine idea to me.

I love magma so my vote goes there, but I think the client has more than enough to be its own repository, or even org if you wanted it outside of FredBoat. There are people who get confused at the whole thing - especially if you're just running the default Java client, because it's easy to misunderstand what the client/server thing entails, moreso when it's bundled and seemingly a single thing.

Another idea on that front is doing what tons of Docker projects, for example, provide -- and that's a curated list of the clients. Yeah, it's done now on the README but I mean actually linking (via submodules or just maintainers like Docker's library) - that way it becomes more clear. That could technically be a repository of its own.

[luaugg]

+1 for replacing jdaa with magma, moving the client to its own repo, and generating version from git tags.

v3 has already been here since PR #91 so it should be okay releasing v3 changes. if it isn't okay, i suggest doing what you briefly covered and adding some backwards compatible behaviour for each "breaking change".

this would be a lot better for users (who don't get confused with builds) and for library devs that try to support v2 and v3. proper versioning for v3 would also help a ton, as all v3 changes count as "v3" even though some break older v3 changes (like how #116 breaks #91). even now, most libs "that support v3" are broken on the latest v3 releases, and up until #111 it was impossible to determine whether a node was on v2 or v3 even tho they should be entirely different "major" releases.

since there have already been literally hundreds of v3 builds prior to this, i suggest releasing the changes as v3.x from now on, and following basic semver for each new change, using github tags/jitpack too. the client could also be moved out to a new repo and then released on either jitpack or bintray too 👍

tl;dr: jdaa -> magma, move client to another repo, versions from git tags and start having proper releases for v3 using something like semver (+1)

[freyacodes]

I believe that https://github.com/Frederikam/Lavalink/pull/119 should be moved to v4.0.

With that out of the way, I think we can merge v3.0 soon.

@napstr I have given you access to https://github.com/Frederikam/Lavalink-Client if you have the time to make the move. I want Sentinel to remain my focus still.

[freyacodes]

Alternatively, we can also move both projects to the FredBoat org

[schnapster]

PR's have been opened for the currently actionable Todos for the 3.0 milestone, as described in OP.