Hi :)

I'd like to suggest some improvements to the way EssentialsX is versioned.

For context - I maintain a permissions plugin which doesn't work "out of the box" with the original Essentials plugin - this has been fixed (#1518) in EssentialsX - so I have to push people your way when they complain to me that Essentials doesn't work 😅

With that said, my suggestions are...

1) Mark clearly that the software is EssentialsX and not just Essentials

This would be really helpful and prevent a lot of confusion. I guess either include it in the version string... so

> about Essentials
[INFO]: Essentials version 2.0.1-b601
[INFO]: Provides an essential, core set of commands for Bukkit.

becomes

> about Essentials
[INFO]: Essentials version EssentialsX 2.0.1-b601
[INFO]: Provides an essential, core set of commands for Bukkit.

or perhaps in the output to /essentials version (#1514) ???

I understand for compatibility reasons the name of the plugin can't change - but including it in the version string shouldn't present any issues. The version in the POM doesn't have to change - it can just be inserted before the placeholder in the plugin.yml file.

2) Use the version string

Knowing that someone is running 2.0.1 is absolutely useless. It hasn't changed in 3 years!

I've had the pleasure of speaking to users who have just completely refused to accept that they're using an old version - because they see no difference in the version of the plugin.

me: hey x, try updating your essentials version
x: but I'm already using the latest!

If you're not planning on ever changing from 2.0.1 - I'd suggest it's removed and replaced entirely by the build number... or if you want to keep the version 2 bit, incorporate the build number into the patch part of the version. e.g. build 601 produces EssentialsX-2.0.601.jar

Alternatively, I've been using Git Tags + this maven plugin to produce unique build numbers for each commit. It also lets you easily generate a list of changes mapped to each version without much effort. :) If you think it's something that could work for Essentials, you're welcome to steal it. 😉

I look forward to hearing your thoughts :)

I think that we just never updated the 2.0.1 because essentials rarely did either.

I'm definitely in favor of having our next release be 2.0.2-b

And we can pull @md678685's PR as soon as he says it's ready :) which it looks like it is now.

Hi Luck - thanks for the input!

Something to note is that incrementing the minor version (2.0 -> 2.1) could eventually conflict with Essentials versioning. While this isn't an obvious major issue at the moment, it could lead to user confusion between EssentialsX versions and Essentials/Spigot Essentials versions.

I think we should definitely start including the build number in the version tag and jar name, but I'm concerned that using the build numbers from the CI means that the version number depends on two Jenkins servers that have to be in sync at all times for consistency's sake (which often isn't the case).

I like the idea of basing patch version numbers on actual commits, but I feel that if we change that, we should also bump the minor version number to give it a meaningful start point. Perhaps we could jump to 2.15.x, which would skip past all released versions of Essentials 2?

(I've mentioned parts of this previously on the Discord server and elsewhere, so if it seems familiar, that's why :p)

Yep, I agree with everything you said :)

Commit hashes are not user friendly. I don't think that having mirrors out of sync is valid enough reason to not use build in favor of hashes. If we want hashes that bad for our benefit, lets embed it in something other than the version string and have it output on startup and in /ess version.

@SupaHam @drtshock The Maven plugin that Luck suggested alleviates both of these issues. The build numbers are dependent on the git history, while still producing unique identifiers for each build that are easy to read and copy.

I'd suggest we have the version numbers in the format 2.minor.patch.commit, where 2 is constant, minor and patch are manually controlled (like in semver) and commit is the number generated by the Maven plugin.

Added <3