Re:Porffor: A from-scratch ahead-of-time JS engine
by derdi on Tuesday July 30, 2024 @04:51PM
(#41114017)
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.
Re:Porffor: A from-scratch ahead-of-time JS engine
by canadahonk on Tuesday July 30, 2024 @07:22PM
(#41115077)
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.
Re:Porffor: A from-scratch ahead-of-time JS engine
by apgwoz on Wednesday July 31, 2024 @08:40PM
(#41125097)
What happens if there’s a regression in coverage, maybe due to a large sweeping change, and you go from 0.40 -> 0.35 ?
Re:Porffor: A from-scratch ahead-of-time JS engine
by astrobe_ on Thursday August 01, 2024 @03:32AM
(#41126937)
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.
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...