For a while we were seeing the files versioned EssentialsX*-2.15.0.613 and then it changed to EssentialsX*-2.15.0.1 (without the actual build number). Is this intentional to no longer include the actual build in the file name itself?

Thanks -Steve

The new versioning system from 2.15 onwards uses the following format: major.minor.patch.commit. major.minor.patch only changes when we post a new release, while commit counts the number of commits since the last release tag. Any time we commit changes to the GitHub repo, we can build from that commit to produce jars that always have the same version number, rather than a mix of bXYZ and bSNAPSHOT.

This means going forwards, the EssentialsX version will never depend on the build number, as this previously led to inconsistent version numbers, sometimes causing the same code to receive different version numbers on each build server.

The build number was included in the version by mistake for two builds on ender.zone due to an oversight in 613e852, and these incorrectly-versioned builds were only installed on around 20 servers. This was rectified in 2.15.0.1 through commit b2a5280, and all subsequent versions use the new versioning system properly.

For more information about the new versioning system, see #1873.

FWIW, to me, the build is just as important as the version when there are frequent builds so I know which one I'm running with. So when I saw the build # as part of the file, I was like "YES!!!" and then it was gone again. :-( If the file only has the version and we don't include the part that is constantly changing, this is where users get confused and have the version mismatched issues that repeatedly get reported.

The problem I have with managing multiple servers and 45-60 plugins on each is having to manually update each file name with the version/build as a visual to see what I'm running with. Having to type in a command to get a version for every plugin is too time consuming and simply not practical from a Server Owner/Admin's perspective. Even if I wrap it in a script or batch file, it's just another step that adds little value (to me).

So what I do for every plugin jar file that gets downloaded is appending the details I need to know.
Dynmap-3.0-SNAPSHOT.jar
EssentialsX-201b612.jar
EssentialsXAntiBUild-2.0.1b612.jar
Jobs4.5.2.jar

I've advocated other plugin owners to do the same to support server owners maintenance and ensuring they are running on the latest version by simply seeing it as part of the file. Not everyone is a fan of this approach, but it is a practice I've been using for decades and it works. :-)

The build number does not represent a specific version of the EssentialsX plugin, as it comes from any one of tens, potentially hundreds of build servers which all have different build numbers, and is not at all influenced by the source code of EssentialsX. That means, builds 700 and 701 could be either exactly the same version of EssentialsX, or could have an entire overhaul of EssentialsX in the middle, but they would receive the versions 2.0.1-b700 and 2.0.1-b701 suggesting they are near identical versions.

In addition, our build servers sometimes get out of sync, meaning that the latest version could be exactly the same code but could have the version numbers b693, b700, b45 and bSNAPSHOT, making them wildly inconsistent and completely meaningless to both developers and users.

In contrast, the new EssentialsX version will increment with every actual change to the source code, as it is calculated directly from the source code history and not an arbitrary counter. This means that builds 700 and 701 could be exactly the same or completely different, but the plugin's reported version such as 2.15.0.1 represents a specific version of the source code, no matter whether I:

• Download it from ender.zone
• Download it from akpmakes.tech (currently broken)
• Download it from another mirror like lucko.me
• Download it from GitHub releases (not yet uploaded)
• Download it from SpigotMC
• Download it from any other official page for the plugin
• Compile it locally on my own server
• Compile it in my dev environment

This means that there is total redundancy - should our main build server go down, all the other latest builds will still work and will still have the same build number. The meaning of 2.15.0.1 never changes for any build of that source version, and it will increment for every actual change to EssentialsX.

TL;DR build numbers are not a good way to track versions, otherwise we'd still be using them.