4 ms·

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 caus

by nick_g 2y ago

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#versioning https://github.com/CanadaHonk/porffor?tab=readme-ov-file#ver...

derdi 2y ago
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 2y ago
  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 2y ago
    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_ 2y ago
      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 2y ago
        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
deleted 2y ago
[deleted]

4 ms·

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 caus

by nick_g 2y ago

derdi 2y ago
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 2y ago
  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 2y ago
    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_ 2y ago
      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 2y ago
        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
deleted 2y ago
[deleted]