Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Think about versioning in the report json #5

Closed
nicojs opened this issue Sep 1, 2018 · 7 comments
Closed

Think about versioning in the report json #5

nicojs opened this issue Sep 1, 2018 · 7 comments

Comments

@nicojs
Copy link
Member

nicojs commented Sep 1, 2018

For example: when showing the report on the dashboard, it needs to know which version to use.

@rouke-broersma
Copy link
Member

I propose that we use semver for both the schema and report components where the report components follow the major.minor versions from the schema, but do not need to have the same patch versions.

@hugo-vrijswijk
Copy link
Member

Perhaps we should also include the version in the report schema json. So on the dashboard, the correct one can be loaded from unpkg

@rouke-broersma
Copy link
Member

Yes that is what I meant as well. The json report should have the schema version it was generated from included as a value.

@nicojs
Copy link
Member Author

nicojs commented Feb 20, 2019

Cool, I like what you're saying. Luckily, unpkg adheres to semver. See https://unpkg.com/. So should just be able to reference it like unpkg.com/mutation-testing-elements@^1.1/dist/mutation-test-elements.js.

I would suggest keeping mutation-test-elements.js versioning in sync with the schema versioning.

@rouke-broersma
Copy link
Member

@nicojs the schema version is currently '1' according to the schema. This is not yet in line with the proposal to use semver.

@nicojs
Copy link
Member Author

nicojs commented Mar 11, 2019

the schema version is currently '1'

What do you mean with that exactly? The version in the package.json file will be automatically released using the lernajs build.

I would like to make a small adjustment:

I would suggest keeping mutation-test-elements.js versioning in sync with the schema versioning.

I think we shouldn't allow patch releases of the schema. It doesn't make sense, as the schema does not have an implementation. I would keep minor versions for additions to the schema and major versions for breaking changes (we should have those as little as posible). The major.minor version of the schema should always be in sync with the major.minor version of the mutation-test-report-app element. For example:

Schema version Supported mutation-testing-elements implementations
1.0 1.0.0, 1.0.1
1.1 1.0.0, 1.0.1, 1.1.0, 1.1.1
2.0 2.0.0, 2.0.1

@rouke-broersma
Copy link
Member

That is what I suggested as well, so I agree :)

I propose that we use semver for both the schema and report components where the report components follow the major.minor versions from the schema, but do not need to have the same patch versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants