[nick_g]

I'm a bit suspicious of the versioning scheme described here[0]

If some change were required which introduced a regression on some Test262 tests, it could cause the version number to regress as well. This means Porffor cannot have both a version number which increases monotonically and the ability to introduce necessary changes which cause Test262 regressions

[0] https://github.com/CanadaHonk/porffor?tab=readme-ov-file#ver...

[derdi]

Presumably the idea is that any work that causes Test262 regressions is temporary, takes place in a separate branch, and is only merged to main once the branch also contains all the necessary fixes to make the regressions go away again. A new version number would only be used once that merge happens.

[canadahonk]

Exactly. The versioning system is definitely unique and controversial, but I think it fits for a fast moving project like this, so I don't have to really consider versioning which could slow development. When it becomes more stable, I'll likely move to a more traditional semver scheme from 1.0.

[apgwoz]

What happens if there’s a regression in coverage, maybe due to a large sweeping change, and you go from 0.40 -> 0.35 ?

[astrobe_]

There's the commit hash. Basically the "version number" is the commit hash, the human-generated (version) numbers added to it are merely progress indicators, which might be randomly useful. But for a project that has 1 branch, 0 tags and nearly 2000 commits, that's not really important.

[apgwoz]

yes, the entire exercise isn’t important. It just breaks the monotonicity that version numbers typically have. At that point, just call your version <progress>.sha