Feature request - Versioning numbers

[xambroz]

Is your feature request related to a problem? Please describe.

Hello. As r2cutter was not starting from 0, but was fork of the Cutter after version 1.12.0 some of the Linux distributions already followed in that versioning and just renamed the package from Cutter to r2cutter - like Arch and Manjaro.

But r2cutter decided to start its versioning from the beginning from v1.12.0 then releasing 0.1.0. and 0.1.1 The version r2cutter 0.1.1 contains newer code than Cutter 1.12.0, but the number is lower. This is causing headache for some version monitoring tools like Repology (https://repology.org/badge/vertical-allrepos/r2cutter.svg?columns=4) or Release-monitoring.org (https://release-monitoring.org/project/185309/)

Describe the solution you'd like Please would you consider to sync with the old versioning scheme and release next release with version number higher than 1.12.0 ... like 1.13.0 or even 1.15.0 (leaving room to re-number the 0.1.0 and 0.1.1 releases).

Describe alternatives you've considered

Additional context

BTW the Cutter.re+rizin just bumped the version to 2.0 so I guess r2cutter can happily continue with the 1.*.0 scheme without any conflicts I guess.

[trufae]

r2cutter is 0.x because it's WIP, but after the next release of r2 (5.2) i plan to make r2cutter version higher than 0.x so distros would be happy again.

Thing is.. i don't like version numbers bigger than 9. One option would be to make r2cutter version in sync with r2 one (r2cutter-5.2 for r2-5.2), another would be to just bump it to 1.13.0 because 2.x would be confusing i guess, if r2cutter is confusing already

[xambroz]

Hello, I understand 0.x is WIP ... problem is that in releases https://github.com/radareorg/r2cutter/releases you already started from 1.12.0, then jumping back to 0.1.0 beta, then 0.1.1 which is causing confusion to tools which are tracking/comparing the versions by numbers.

In packaging for linux distributions this is doable to handle with introducing epochs like 1:1.12.0 is lower than 2:0.1.1 ... but it looks ugly and if possible I would like to avoid it. Continuing next release with something numerically higher than 1.12.0 would help.

Thing is.. i don't like version numbers bigger than 9.

What about syncing it with the r2 release major numbers ... would that make sense to more or less announce which radare2 version it is related to? Like 5.1.1 ?

Thank you Michal Ambroz

[trufae]

Ok, after a bunch of conversations with the original author and other members of the community i decided the following:

• Rename r2cutter to iaito
  • this was the original name of this program before being forked by the actual developers)
  • remove the confussion between cutter and r2cutter (rizin vs r2)
• Follow the same version numbers as r2 because api compat is needed and that's the cleanest way to do so

So, in order to release the following changes should be done:

• [x] Rebrand/rename the whole thing again
• [x] Bring back the original icon
• [x] Wait for the r2-5.2 release to fix the CI compilation
• [ ] Fix the remaining warnings (that will probably make qt6 work (right now it builds but doesnt run fine under qt6)
• [ ] kill the cutter-deps repository and just use distro provided packages
• [x] Use the new crowdin based translations.

How does it sound? I know all distros are in a little hurry to get that release up, but i think the waiting will be good.

Help is welcome if anyone is interested in having it earlier

[xambroz]

Pity renaming again, but understandable. Version numbers sync with r2 api sounds reasonable. Thank you.

[trufae]

Rebranding done in git, i converted the list of items to checkboxes. moving forward :)

[xambroz]

Thank you.

[trufae]

I think now it’s good for a release. Further improvements and warn fixes can come later when distros start to package and the software gets some visibility.

[trufae]

Release done!