[Done] Plugin Versioning

[lokka30]

How do you think Treasury should be versioned?

I was going to just use a build system where each development build and release of Treasury just increments the number, but I've heard that using the commit ID could be a better solution. What do you think?

[MrNemo64]

Increasing a version number is more user friendly than a commit id in my opinion. I haven't heard anything about using commits id instead of build versions

[lokka30]

We need a way to identify different builds from each other.

For example, we can work on Treasury v1.1.0. The version is rarely complete in a single commit, there may be multiple variations until we are happy with the state of Treasury v1.1.0 and release it. This could mean the version is Treasury v1.1.0 b5 (build 5)
I think this is the most user friendly solution.
With this I am unsure whether the build number should be global or per-version. e.g. should the number reset with each version?
I am also unsure how this can be automated. I know there is an IntelliJ plugin that does it but I don't know if it's satisfactory enough for our requirements.

Or, we can consistently increase the version and release whichever version is the good one and supply the changelogs of all the past unreleased versions. e.g. we start with Treasury v1.1.0 but only v1.1.5 is released.

Another alternative is to supply the same version name throughout its development (v1.1.0) but add the commit ID as a suffix.

[MrNemo64]

For example, we can work on Treasury v1.1.0. The version is rarely complete in a single commit, there may be multiple variations until we are happy with the state of Treasury v1.1.0 and release it. This could mean the version is Treasury v1.1.0 b5 (build 5)

So a commit, for example, to fix identation would mean a new build? I like the build idea but not for every commit

With this I am unsure whether the build number should be global or per-version. e.g. should the number reset with each version?

Yes. It doesn't make sense to go from 1.0.0 to 1.0.1 to 1.1.1 but it makes sense to go from 1.0.0 to 1.0.1 to 1.1.0

Or, we can consistently increase the version and release whichever version is the good one and supply the changelogs of all the past unreleased versions. e.g. we start with Treasury v1.1.0 but only v1.1.5 is released.

People would wonder what happend to the in between versions, I don't know if this is a good idea.

Another alternative is to supply the same version name throughout its development (v1.1.0) but add the commit ID as a suffix.

Could be but commits are like identificators of the state of the code, not the build. Some changes in code don't mean changes in the project so making another build for it doesn't seem right

[lokka30]

This is the current format I have in mind. I know it's quite long but it has all the details one will need.

• name-platform-version-build-status

Examples:

• Treasury-bukkit-v1.2.3-b4-RELEASE
• Treasury-sponge-v2.0.1-b12-SNAPSHOT

The build number is for the specific version. Say we are working on Treasury v1.2.3, but it takes 4 builds or commits to get to the release stage. Therefore there will be 4 builds of that version. The build number is back to 1 when working on the next version.

The status text is either RELEASE or SNAPSHOT, making it easy to identify if a version could be unstable. We could always publish snapshots to Spigot etc if we wanted to, but ideally we always post 'release' versions which are very stable (to our knowledge).

I think manually incrementing the build number is fine.

[Jikoo]

The thing I don't like about build numbers is they're largely just a system-specific magic value. A commit short hash is not user friendly, but it is developer friendly - it makes it very clear exactly where the version being run is in history. As long as it's included in a larger segment that should all be copied and pasted, it should be easy to retrieve from users in a debug command.

Re: specific patterning - generally for a release all that is needed is artifact-version (i.e. treasury-bukkit-v1.2.3.jar) because it is the single release for that version. By using specific profiles, it's possible to set that up automatically for building on tag.

[Jikoo]

If we do want to just make it so that each new commit to master is a new version, we should probably disallow direct commits so that any work between versions will not result in version bumps. MockBukkit is a good example of this; pretty much all work, no matter how small, is done via PR. There's even a PR open to automatically bump version on merge based on tags.

[lokka30]

My current idea is to make development branches which just merge into master when a release is ready. Do you think this is a better/worse system than PRs?

[Jikoo]

That also works. It's stylistic choice - you seem to prefer merging as-is, I prefer a squash. With GitHub's PR merge system, even if you do a squash, the PR preserves the pre-squash commit history (/e: even if the original branch is then deleted, which is nice for keeping the repo clean). The main branch then doesn't contain commits like "adjust style per request" etc. which I find to be aesthetically pleasing, but you can still view the specific detailed history in the PR itself.

[lokka30]

I've never created a PR to a repository I own before. Do you have any experience with this?
Squashing sounds like a great idea.

[MrIvanPlays]

Not all commits shall become releases in my opinion. Only specific ones.

We shall use commit hashes in my opinion, because as jikoo said build numbers are a system specific magic value.

Re: specific patterning - I like how IntelliJ's doing it but instead of build number we will have the commit hash: e.g the version would be 1.2.3-d66fff0 and the distributed jar name - treasury-<platform>-<version>.

[lokka30]

It is mostly system-specific, that's right unfortunately. I think commit hashes are the way to go. I noticed you excluded the status - RELEASE/SNAPSHOT - is this intentional?

[MrIvanPlays]

Actually now that I think of it we might need them for spigot version checking.

[lokka30]

Assuming the current format is:

Treasury-platform-version-commit-status

Example: Treasury-bukkit-v1.2.3-d66fff0-RELEASE

I'm sure the update checker needs to be adjusted as well