Aergo Version

[kroggen]

The current version number 2.4.7 is not compatible with the current hardfork number 3

It would be a good idea to make the major version to match the hardfork version

On this case we would change the next version to be something like 3.0.8 or 3.4.8 instead of 2.4.8

The source code packages would change from /v2/ to /v3/

And then when the next hardfork version 4 (V4) is released, the major version would be 4

Unless we make a direct jump from /v2/ to /v4/ later (is this allowed?)

What do you think?

[rabbitprincess]

i think change major version by hardfork do not need.
and also, change major version have some side effects.
https://www.wagslane.dev/posts/gos-major-version-handling/

in my opinion, it is no problem with the v2 version.

[ultrafellen]

I think the version of AERGO and the hard forked version should be seen as separate.
Also, we �follow this rules - semantic versioning https://semver.org/

[kroggen]

I was expecting the major version to change when a new hardfork is released, according to semantic versioning rules

If a new hardfork is required, it means the code is not compatible with the previous version

[kroggen]

I saw now that the changes are restricted to "API" on semver. I did not know that

[ultrafellen]

For example, if look at geth, there have already been several hardforks, and the major version is not going up, only the minor version.

[kroggen]

Indeed, there are many node implementations (Go, python, etc) and each one has its own version
It is different from the EVM version