Essentials: Versioning improvements

[lucko]

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. :wink:

I look forward to hearing your thoughts :)

[drtshock]

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.

[mdcfe]

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)

[lucko]

Yep, I agree with everything you said :)

[SupaHam]

Hey,

I've discussed my opinions on this before over discord.

I suggested that the git hash of the commit being built be included in all
dev builds. Then, official builds, which should be generated based on a
commit that will only update the versions in pom.xml, will only include the
unique version.

Build numbers are not a reliable solution because it is limiting in our
freedom as developers. You don't want to put mirrors out of sync. Or have
your users think they missed out on a dozen updates because there's a
difference of 10 builds, when really it was a CI change that was made, not
actual software.

It is so easy to do, and build numbers shouldn't benefit users except only
for using them as a reference point in casual conversation.

On Mar 6, 2018 11:14 PM, "md678685" [e-mail] wrote:

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)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/EssentialsX/Essentials/issues/1873#issuecomment-370963515,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPV0fl0vdbwZ9FAppEmcPommFRc1vTFks5tbxhOgaJpZM4SbGgF
.

[drtshock]

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.

[mdcfe]

@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.

[drtshock]

Added <3