KTX versioning

[czyzby]

As most of the major features were added and the API reaches maturity, I believe it's time for a stable release. #73

Originally KTX shared versions with LibGDX, being a direct extension of this library. This worked well as long as we used the suffixes such as -b1, as the KTX version clearly showed the compatible LibGDX, but we also had a way to increment our own version. As we reach the stable release, this becomes more complicated.

Here are some examples of how we could approach KTX versioning.

---

1) Share the version with LibGDX

We could do a single stable release for each LibGDX version, and possibly fix releases in case of major bugs. The first stable release would be 1.9.10.

Pros:

• KTX version clearly points to the appropriate LibGDX version.

Cons:

• We become completely dependant of LibGDX release cycle (which gets worse, as far as I can see) and would probably have to resort to suffixes either way.
• As LibGDX does not use true semantic versioning, neither would we.

2) Share the version with LibGDX, but with a suffix

Similarly to how we currently add a beta suffix, we could go with .# or -# which points to the current KTX iteration. The first stable release would be 1.9.10-0 or 1.9.10.0.

Pros:

• KTX version points to the appropriate LibGDX version.

Cons:

• This is not semantic versioning. Version increments for major API changes and minor bug fixes would be identical.
• The version is starting to look like an IP address.

3) Share the version with LibGDX, but add semantic versioning on top of that.

A variation on the suffix approach. We could add our own semantic versioning to current LibGDX version. The first stable release would be 1.9.10.1.0.0 or 1.9.10-1.0.0.

Pros:

• KTX version points to the appropriate LibGDX version.
• We are now using a variation of semantic versioning, which would clearly mark the type of changes added to the library.

Cons:

• The version seems long and convoluted. Might not be clear for the users.

4) Custom versioning of each module individually

In this approach, we would no longer incorporate the LibGDX version. Instead, each module would use separate semantic versioning, starting from 2.0.0 (to appear newer than the existing 1.9.X-bX releases).

Pros:

• True semantic versioning.
• Each module will clearly mark the type of changes that the user can expect.

Cons:

• Increased maintenance for the users. Each module has to be tracked separately. Common KTX version cannot be extracted.
• Increased maintenance for the contributors. Separate version and changelog has to be updated for each module.
• Required LibGDX version is no longer reflected by the version. LibGDX might have to be converted from provided to a regular dependency.

5) Custom versioning of KTX globally

A single semantic version for KTX as a whole. Each bug fix, refactoring and performance improvement that does not change the public API increments the PATCH version. Each new feature increments the MINOR version. Each breaking change increments the MAJOR version. The first stable release would be 2.0.0.

Pros:

• A form of semantic versioning that is correct when considering KTX as a whole.
• Users and contributors have to maintain only a single KTX version.
• Version clearly marks if there were any additional features or breaking changes.

Cons:

• Required LibGDX version is no longer reflected by the version. LibGDX might have to be converted from provided to a regular dependency.
• It is likely that the version of some modules will be incremented even if there were no changes in them in particular. However, this has always been the case.

---

I'm leaning towards the 5) solution, but I'll leave this issue as open for discussion.

[Quillraven]

I personally like the version of libgdx in the ktx version because it makes it is easy to see that it is designed for a specific libgdx version.

However, libgdx release cycle seems to be once a year or less while ktx (at least currently) improves consistently every couple of weeks/months.

Also, currently I use libgdx 1.9.11 snapshot in one of my projects with ktx 1.9.10 (since there is no 1.9.11 version) and it does not seem to break anything.

For those reasons I would also go for an independent versioning which would be option 5. I would not go for a versioning per module because that would make the build file less intuitive to read and also instead of having one ktx version you would need to define multiple ones in worst case?

Therefore, option 5 is my pick.

Out of interest: what speaks against a date in versions like "ktx version 20200502"? Is it that you no longer can tell the difference between a major and minor release?

[czyzby]

Out of interest: what speaks against a date in versions like "ktx version 20200502"? Is it that you no longer can tell the difference between a major and minor release?

Exactly. It might be a good idea for desktop applications, where you worry less about the API (if there is any), and more about having the latest version with full customer support, new features and crucial bug fixes.

When it comes to libraries like KTX, it's more important for the users to know if their applications can potentially break or if they can expect new features after updating. Semantic versioning does that. That - combined with the slow release cycle of LibGDX - is why I think KTX should have separate versioning after all.

[czyzby]

KTX switched to the rc suffix, so that it's considered a stable release by Maven Central, but it still relies on the libGDX version. I think this might be the way to go for now, since both KTX and libGDX mostly get maintenance releases these days. I might reconsider in the future in case of new contributions or major changes within libGDX itself.