search

godotengine / godot-asset-library

PHP frontend for Godot Engine's asset library
https://godotengine.org/asset-library
MIT License
292 stars 87 forks source link

No 3.1.1 in Godot version list #181

Closed MightyPrinny closed 5 years ago

MightyPrinny commented 5 years ago

3.1.1 is not listed under "Godot version" when submitting an asset.

menip commented 5 years ago

It seems there are no patch versions at all when it comes to AssetLib. I think it should be left like this, a Major.Minor version is enough info without cluttering.

MightyPrinny commented 5 years ago

the 3.0.x patches are there.

bojidar-bg commented 5 years ago

This should be easy to fix by adding the constant here: https://github.com/godotengine/godot-asset-library/blob/8d03dc9bec0ca61a4e3d21aaf517245e6082cf37/src/constants.php#L68

akien-mga commented 5 years ago

We might want to drop the patch version constants though, I think most users are confused by them.

The intent was so that you can indicate that an asset is made for Godot 3.1.1+ and will not work in 3.1-stable, if it uses features added in the patch release. But the vast majority of assets should work just fine on any 3.1.x, and if some do not work on older patch releases, these patch releases will soon enough be phased out so that it's no longer relevant.

merumelu commented 5 years ago

Speaking about the version list, is there really a need to include 1.0, 1.1, and 2.2? The last one never even had an official release.

akien-mga commented 5 years ago

Maybe we can query stable.json entries from https://godotengine.org/mirrorlist/ to avoid maintaining this list manually?

Not sure how to retrieve the list over HTTP but it's on the same domain as the assetlib itself, so we can likely just query the local files.

$ ls mirrorlist/
3.0.1.stable.json       3.0.3.rc1.mono.json     3.0.4.stable.json       3.0-devel.mono.json     3.1.alpha.json        3.1.beta1.mono.json  3.1.beta5.json       3.1.beta8.mono.json  3.1.rc3.json
3.0.1.stable.mono.json  3.0.3.rc2.json          3.0.4.stable.mono.json  3.0-stable.json         3.1.alpha.mono.json   3.1.beta2.json       3.1.beta5.mono.json  3.1.beta9.json       3.1.rc3.mono.json
3.0.2.devel.json        3.0.3.rc2.mono.json     3.0.5.stable.json       3.0-stable.mono.json    3.1.beta10.json       3.1.beta2.mono.json  3.1.beta6.json       3.1.beta9.mono.json  3.1.stable.json
3.0.2.devel.mono.json   3.0.3.rc3.json          3.0.5.stable.mono.json  3.1.1.rc1.json          3.1.beta10.mono.json  3.1.beta3.json       3.1.beta6.mono.json  3.1.rc1.json         3.1.stable.mono.json
3.0.2.stable.json       3.0.3.rc3.mono.json     3.0.6.stable.json       3.1.1.rc1.mono.json     3.1.beta11.json       3.1.beta3.mono.json  3.1.beta7.json       3.1.rc1.mono.json
3.0.2.stable.mono.json  3.0.3.stable.json       3.0.6.stable.mono.json  3.1.1.stable.json       3.1.beta11.mono.json  3.1.beta4.json       3.1.beta7.mono.json  3.1.rc2.json
3.0.3.rc1.json          3.0.3.stable.mono.json  3.0-devel.json          3.1.1.stable.mono.json  3.1.beta1.json        3.1.beta4.mono.json  3.1.beta8.json       3.1.rc2.mono.json

If we go with this option, I can add .json files for 2.1.x.

That doesn't solve the actual issue with this versioning though, which is discussed in #156.

akien-mga commented 5 years ago

For now I think the simplest fix is to keep only 2.1, 3.0, 3.1 and 3.2. We don't need the granularity offered by patch versions in 99% of cases.