question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

All exercise test files should reference canonical data version

See original GitHub issue

Currently some of the test files reference x-common//canonical-data.json with a version number, and a few test files lack any such a reference. Additionally, x-common was recently renamed to problem-specifications, so references to x-common are inherently outdated and potentially confusing.

Having a consistent version string should help with maintenance, since a script can fairly easily be written to compare the version numbers in the test file and the canonical data, and manual checks for how up to date it is are similarly easy. It also makes it easier for exercism users to find and check the canonical data, and thus to be able to contribute any changes they think are necessary if they identify problems or additional tests that would be useful.

Suggested wording

The currently adopted form for the version string seems to be: # test cases adapted from `x-common//canonical-data.json` @ version: 1.0.1

To conform to PEP8, we should aim to limit the string to 79 characters, so I propose the following wording (75 chars): # Tests adapted from `problem-specifications//canonical-data.json` @ v2.0.0

Does anyone have any alternatives or suggestions for improvements to this wording?

How to proceed

There are a couple of options for how to go about updating the test files:

  1. Only update version strings when the tests are next updated, and update tests when the canonical data change.
  2. Systematically update each test file to match the most recent canonical data version (or verify that it’s already up-to-date), and update the version strings in the process.

Option 1 is obviously the less work-intensive one, but it would leave some inconsistency for quite a while. Option 2 is more work-intensive and should get everything up-to-date quicker, but it might burn people out a bit.

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Reactions:2
  • Comments:14 (14 by maintainers)

github_iconTop GitHub Comments

1reaction
N-Parsonscommented, Oct 25, 2017

@m-a-ge, all of the issues should now be created and correctly labelled 😃

1reaction
N-Parsonscommented, Oct 9, 2017

I had some free time this evening, so I put together a fairly rough script for checking the state of version numbering. I put the results into a gist to save making a very long post here, and I have summarised the results below.

Up-to-date: 33 Out-of-date: 8 Unknown: 31 (no version tag) Unimplemented: 27 No canonical data: 14 No data needed: 5 (maybe more - requires manual checks)

Read more comments on GitHub >

github_iconTop Results From Across the Web

problem-specifications/canonical-data.schema.json at main
This is a JSON Schema for 'canonical-data.json' files. ",. " ",. " It enforces just a general structure for all exercises, ",.
Read more >
Versioning and Canonical URLs - Firely
If you need to bump the version in a canonical url in the set that you publish, you need to be really sure...
Read more >
Canonical Tags: A Simple Guide for Beginners - Ahrefs
Canonical tags help to combat duplicate content issues. They tell search engines like Google to index and rank the right pages.
Read more >
Canonical Workflow for Machine Learning Tasks
The Exp_Meta_FDO description needs to be extended to include a reference (PID) to the Exp_Col_FDO and eventually parameters in the experiment ...
Read more >
5 common mistakes with rel=canonical - Google Developers
A large portion of the duplicate page's content should be present on the canonical version. One test is to imagine you don't understand...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found