search

markusfisch / BinaryEye

Yet another barcode scanner for Android
https://play.google.com/store/apps/details?id=de.markusfisch.android.binaryeye
MIT License
1.26k stars 108 forks source link

ZXing-CPP Wrapper: Request for different versioning format #450

Closed michaeltroger closed 2 months ago

michaeltroger commented 3 months ago

First thx for providing this app and the ZXing-CPP fork. I really appreciate how intuitive and performant they work!

Just a minor thing: Could you consider releasing your Android library in the common MAJOR.MINOR.PATCH format, so without the preceding "v"?

The "v" seems to break some auto-dependency update scripts and also in my Android Studio Koala, I don't receive update suggestions.

Seems the original https://github.com/zxing-cpp/zxing-cpp uses the "v" for Git tags as well, however the official library is then released without: https://mvnrepository.com/artifact/io.github.zxing-cpp/android

Sorry for the slight off-topic in this repo (issues seem to be disabled in the library repo)!

markusfisch commented 2 months ago

Actually I would very much like to drop that "v" too! The sole reason it's there is because the original repository had it, and I wanted to keep the original version information in my distribution. Which is why I just append a number to the original version when tagging a new version of my fork.

This (in my opinion nonsensical) "v" prefix is probably a good example of an unreflectedly propagated best practice whose original justification has either been lost or was never really formulated due to a lack of sense. In SemVer v1.0.0 (under SemVerTag), it was suggested that releases in VCS be tagged with version numbers with a leading "v", but there is no rationale for it. Consequently, this was removed in v2.0.0 (pun not intended). Maybe some people just don't like names to begin with numbers 😉

Now, I just added a tag without the "v" for the latest version: "2.2.0.5". I hope having four components (instead of the usual three) is not a problem. If so, I will need to come up with a different scheme that somehow preserves the original tag information.

michaeltroger commented 2 months ago

Sorry if I didn't phrase myself properly. I was asking for the publishing version of the artifact only: https://github.com/markusfisch/BinaryEye/blob/master/app/build.gradle#L82 So generally the Git tag would be an implementation detail not (directly) relevant for me. But TBH I don't know how the release on JitPack is done. So I could imagine that the artifact name would be dependent on the Git tag 🤷

Ah and yeah true I missed the 4 components part, but I think that's not the problem. I'm using another lib with that format and update suggestions work:

Screenshot 2024-04-21 at 17 40 07

Anyhow it's really not a big deal, and if I were you I would also try to keep close to upstream for avoiding too much maintenance effort! I was just curious if it would be easily doable since their official Android artifact is also without the preceding "v". Thx for your time!

markusfisch commented 2 months ago

So I could imagine that the artifact name would be dependent on the Git tag

Exactly, JitPack creates the artefact from a tag, and the artifact name comes directly from the tag 😉 So this is essential always the same, and there is no extra configuration required.

The Android artifact of the original repository, on the other hand, is distributed via Sonatype which requires some manual configuration.

If the new tag is working for you I would close this issue now?

michaeltroger commented 2 months ago

I see, thx! Yeah, looks good now