Deploy release version of Floodgate API

[A248]

What feature do you want to see added?

At the moment, the Floodgate API is deployed as a SNAPSHOT version to the maven repository. For example, 2.0-SNAPSHOT

Snapshot versions are unstable because they are prone to change. This in turn makes builds unstable. A stable build is often necessary for re-visting older versions to test certain behavior, which is very helpful in tracking down bugs.

Are there any alternatives?

Timestamped snapshots provide a temporary reprieve, but they have their own troubles.

In case the reader is unfamiliar, a timestamped snapshot is a niche feature which allows depending upon a specific SNAPSHOT version. A timestamped version might look like: 2.0-20210504.141729-27.

[Tim203]

We never really used to work with stable versions, instead every version is a snapshot version.
However, I feel like this is going to change with 2.1.1 (we're moving from maven to gradle).

And about your alternative; I looked into it, and I'm able to use a timestamped snapshot already:
org.geysermc.floodgate:api:2.0-20210323.183625-1

[A248]

I noticed you moved to Gradle and published 2.2.0-SNAPSHOT. Is there anything that needs to be done which blocks releasing a stable version? I'd like to depend on the Floodgate API without the instability of snapshot versions.

[Tim203]

Yeah, sorry about the lack of communication here.
After some internal discussion we decided to not use release versions at the moment, because we don't want to be limited by a release cycle and instead push changes to the general public when we feel like they are ready.

However, from what I remember, the discussion was just about having a release version for all modules and an option to release just the API module wasn't really discussed.
Just releasing the API module does add additional complexity to the project and might become confusing when all the other modules report snapshot versions.
I'll bring this up as an idea and will respond here once there is an update.

[A248]

Hey Tim203,

I am revisiting this and wondering whether you had any update. No rush of course, but I would dearly like to depend on a release version. Adding Geyser integration would benefit users of both our plugins greatly (A248/LibertyBans#173). Keep me posted.

[Tim203]

Thanks for your patience on this.

After some internal discussion we decided to not work with API release versions as we're planning to move to an API shared between Geyser and Floodgate in the near future (Geyser is already using this API).
The API in the development branch reflects the final version of the Floodgate API and marks some classes and methods as deprecated. Those deprecated methods won't have a direct alternative in the combined API.
While we move away from the Floodgate API to the shared API we will still support the Floodgate API for quite some time (I would expect at least 2 major Minecraft releases) before we remove it permanently.
Because of these plans, we don't think that it's worth moving to a release cycle just for an API version that's marked as release. A release cycle for Floodgate might be considered sometime in the future, but that's not relevant for your request.

We are however interested in hearing what you have to say about having release versions for the combined API that will be used in both Geyser and Floodgate.

[Camotoy]

Additionally, I am interested to hear what concerns you have about timestamped snapshot versions.

[A248]

Release versions for the combined API you plan to use would be a splendid idea. Providing releases is an excellent way to help guarantee stability to your dependents. This is especially true for libraries which depend on the Floodgate API, since propagating snapshot dependencies to library consumers often seems unwise.

In terms of limiting flexibility, release versions are consistent with a stable semantically versioned API. If you already provide API stability per semver, no change is necessary; releases will better communicate your position.

Otherwise I find very little downside to releases. Sure, adopting semver might require your team to more closely consider API changes: but such consideration benefits API consumers. Strictly speaking, adherence to semver is separate from providing release versions, but in practice the two strategies cooperate well in communicating intention and providing stability.

I am interested to hear what concerns you have about timestamped snapshot versions.

I have relied on timestamped snapshot versions on several occasions for other dependencies without release versions. They are error-prone and tend to not work well with other parts of the Maven ecosystem. For example, the maven-enforcer-plugin considers a timestamped snapshot as failing the "enforce-no-snapshots" rule. There were some other bugs in different Maven components relating to timestamped snapshots. I remember debugging dependency resolution issues and discovering MENFORCER-298 as culprit and this JIRA comment as solution.

More generally, timestamped snapshots were never meant to be used as a replacement for full release versions. They're a niche feature primarily useful for debugging purposes. Contributors often don't understand timestamped snapshots and don't know how to update them (mvn versions:lock-snapshots). In contrast, release versions have none such problems.