4 ms·
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
by 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 agoExactly. 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 agoWhat 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 agoThere'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 agoyes, 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