Arch Linux User Repository

In that case, I'd say bump to version 3, and do number of commits + hash.
So 3-xxx-hash.

@txtsd interesting. currently the version number points, by convention, to a commit in the source code. the code itself has it, the jar file is named like this, it is displayed in the GUI, the update check is based on it. if an error report comes in, it is clear what version it is. no matter if it is released or not. a release is a "no operation", jar file stays the same, same name, same contents. only action is to enter the new version in the repository, so the update check of a running app finds it. the no-op release means, you know the name of a release already beforehand, and every commit can lead to a release. i am open for any version number scheme, as long as these properties are fulfilled.

arch linux does not need any update check in the application, thanks to rolling model. unfortunately the world is not arch only. thanks for the version update in PKGBUILD - i think putting the real number would prevent that the app wants to update itself.

@soloturn It should not be upstream's job to pin a hash, that is downstream's responsibility. Upstream should be allowed to move tags around.
At least on Arch Linux, the hash for the tag/branch commit is stored in the checksums array, so if upstream moves tags, it will reflect.

I suggest using year.month.release_number, so a new release would be 2024.12.1.

hey thanks guys for setting the version into the gradle build. in PKGBUILD you might consider referring to git hash ca96ce88 instead of tag 2.1.12 to get source code for 2.1.11-20-ca96ce88. everybody can move around the tag as he likes and you might get a different source code from one day to another.

with the number i see your point. 2.1.11 should facilitate ordering only, semantic it was from before adopting git hash in version. ripme is no API where increase patch for fix, minor for addition, and major for break make sense. we could remove the 3 digit semantic version and just have one or two numbers:

• 20-ca96ce88, then 100-hash, xxxx-hash and so on. just the number of commits, and the commit hash.
• or: 3-20-ca96ce88, then 4-xxx-hash and so on. some manual next number, number of commits since last tag, and hash.

@soloturn That is something that -git packages do.

Could you fix the versioning upstream instead? In semantic versioning, all those changes should ideally bump the patch version, if they're less relevant than bumping the minor version.

The way it's going currently, we'll be on 2.1.x forever with unnecessarily complex versions. Just bump the patch version normally.

would you mind to give it the real version including the git hash, so the update logic does not warn for newest on server? 2.1.9-7-e915df means tag 2.1.9 + seven commits and the git hash of this commit.

@soloturn I did it on ripme-git. ripme 2.1.6 does not contain the customVersion commit.

you could now drop the patch, and set the version via

gradle clean build -PcustomVersion=$pkgver-$pkgrel

high enough so it does not offer to download a newer one.

@soloturn Done. Thanks for the tip!

this should work with the latest gradle version, so make dependency to gradle would be fine instead of using gradlew.