[Issue]: Versioning conformance tests
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Quiet
- Tech stack
- python
- Domain
- release, testing-qa
Research direction
Start by locating the conformance package and testing framework, then inspect how package and spec versions are currently represented and released. Review the linked versioning guidance and the discussion before proposing a scheme that supports synchronized and independent changes; done means the versioning policy and its handling of supported spec versions are agreed.
Written by the indexing model from the issue text.
Description
Describe the issue
@clbarnes and other folks, I wanted to open this issue to discuss versioning for the conformance tests and testing framework.
However we choose to package/distribute the tests for downstream consumption, we'll want to make sure that:
- the conformance package version and spec version can be kept in sync
- the conformance package version and spec version can be changed independently
In GEFF we use a hybrid versioning scheme consisting of 5 numbers. For the conformance testing package, this could look like vX.Y.Z.A.B where vA.B would be the highest supported version of the spec. The numbers X.Y.Z could be bumped according to semver, effver, or any other suitable versioning scheme.
Let's say we cut a new version of this conformance package (say "v0.1.0") for spec release v0.6. Under the hybrid versioning scheme, this could be v0.1.0.0.6. If we realized there was a bug in the package, we could release v0.1.1.0.6. If version 0.7 of the spec is released, we'd probably be adding new features to the tests, so we could release v0.2.0.0.7... etc.
We'll have to think about what that looks like with v0.4 and v0.5 re. "the highest supported version".
- Dominant language
- Python
- Stars
- 14
- Forks
- 19
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ome/ngff-spec
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 Half a day Newbie friendliness 67/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
-
comp/desktop P3 type/feature
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
NousResearch/hermes-agent#154285 ·
Maintainers usually reply within 1 day
-
docs: qualify copied and custom kubectl debug policy notesPossibly taken @nym01 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
kubescape/cel-admission-library#166 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
SACGF/variantgrid#2804 · 1 comment ·
Maintainers usually reply within 1 day
-
[BUG] HTTP lifecycle dispatch treats a NO_PROXY-only environment as corporate egress and skips the resolve-and-pinned sessionPossibly taken @bodapatisaikrishna claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day