Prefix tags with v to allow Go to properly detect package versions

[t0rr3sp3dr0]

Currently, tags consist of the version number of Unicorn and are not prefixed with v. This causes Go to not recognize the versions properly. Version 2.1.1 is being recognized as v0.0.0-20240926111503-d568885d64c8, see https://pkg.go.dev/github.com/unicorn-engine/unicorn?tab=versions.

Furthermore, since the current version is >= 2, we should add the /v2 suffix to the package name. See https://go.dev/blog/v2-go-modules.

[wtdcode]

I have no idea about this. Is it a good practice to have two tags?

[t0rr3sp3dr0]

No, it’s not ideal to have two tags. But it’s up to you at the end. My suggestion would be to start publishing tags with the v prefix moving forward. Maybe in a 2.2.0 release.

But I honestly don’t know if there’s some other language that expects the tags not to be prefixed with v or if it would cause other problems. I can only speak to the Go side of things.

Do you know if we have bindings for some language that uses this repository directly like Go does?

[wtdcode]

The other case is rust but cargo supports arbitrary format of tags, even hashes.

…

________________________________ From: Pedro T?rres ***@***.***> Sent: Saturday, December 21, 2024 12:02:22 PM To: unicorn-engine/unicorn ***@***.***> Cc: lazymio ***@***.***>; Comment ***@***.***> Subject: Re: [unicorn-engine/unicorn] Prefix tags with `v` to allow Go to properly detect package versions (Issue #2068) No, it’s not ideal to have two tags. But it’s up to you at the end. My suggestion would be to start publishing tags with the v prefix moving forward. Maybe on a 2.2.0 release. But I honestly don’t know if there’s some other language that expects the tags not to be prefixed with v or would cause some problem. I can only speak to the Go side of things. Do you know if we have binding for some language that uses this repository directly like Go does? ― Reply to this email directly, view it on GitHub<#2068 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHJULO25VMZ5N3FWR6YSBTT2GTR45AVCNFSM6AAAAABT744YLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJXHE4DGNBRGQ>. You are receiving this because you commented.Message ID: ***@***.***>

[Antelox]

FWIW I wanted to derive the version from git tags in python bindings too, but last time I tried it was problematic due to tags format indeed. They were not following the versioning format that python expects to find. A workaround for this would be that of accept the tag as-is but I don’t really like it, I would prefer having proper tags indeed. I was using versioningit lib FYI.

If needed I can make some tries and show what it was the issue.

[Antelox]

I have made the change in my own fork and it worked fine with current tag format (without the v). In case we add, it will continue to be ok too.
The only issue is with some older tags that don’t follow the format expected by python but I suppose we will not be building old commits :)

[t0rr3sp3dr0]

I took a look at the Python and Rust versioning systems, and while Rust uses SemVer (just like Go), Python does not. So we would have some conflicts:

Python	SemVer
1.2.0.dev1	0.y.z (maybe 1.2.0-dev.1)
1.2.0a1	1.2.0-alpha.1
1.2.0b1	1.2.0-beta.1
1.2.0rc1	1.2.0-rc.1
1.2.0.post1	not supported (maybe 1.2.0-post.1)
1.2.0a1.post1	not supported (maybe 1.2.0-alpha.1-post.1)

[t0rr3sp3dr0]

Also, Rust doesn't prefix versions with v. But that only applies when publishing to https://crates.io. It's trivial to remove the prefix in a pipeline, before publishing.

[t0rr3sp3dr0]

It's also easy to convert from SemVer to Python, but only if we stop tagging post-releases and never have development releases.

[t0rr3sp3dr0]

I've added some alternatives to the table above that would support post and dev releases. But I honestly think it's better not to have them and release a new patch version if needed.

[wtdcode]

I've added some alternatives to the table above that would support post and dev releases. But I honestly think it's better not to have them and release a new patch version if needed.

Thanks for suggestions and your investigation. I will try to tag a release with v prefix next time, but a few CI workflows might be adapted. Will have a look until nextrelease.

[Antelox]

Speaking of python binding, the build backend we use here is setuptools, and in case of a tag following semver, it normalizes to the python versioning format. So not an issue.

[wtdcode]

I’m going to simply do a v-prefixed tag but still update ordinary versions in bindings like setup.py or cargo.toml.

…

________________________________ From: @Antelox ***@***.***> Sent: Sunday, December 22, 2024 4:17:57 PM To: unicorn-engine/unicorn ***@***.***> Cc: lazymio ***@***.***>; Comment ***@***.***> Subject: Re: [unicorn-engine/unicorn] Prefix tags with `v` to allow Go to properly detect package versions (Issue #2068) Speaking of python binding, the build backend we use here is setuptools, and in case of a tag following semver, it normalizes to the python versioning format. So not an issue. ― Reply to this email directly, view it on GitHub<#2068 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHJULOYSOETSEWXEN24TUG32GZYTLAVCNFSM6AAAAABT744YLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJYGM3TGMJQHE>. You are receiving this because you commented.Message ID: ***@***.***>

[Antelox]

I’m going to simply do a v-prefixed tag but still update ordinary versions in bindings like setup.py or cargo.toml

For python not needed, we can just use dynamic versioning in toml via versioningit. I have a PR ready that also takes care of running actual regress tests plus some refactoring to the GitHub action workflow