-
-
Notifications
You must be signed in to change notification settings - Fork 555
Nonstandard metadata.yml
properties
#597
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
Comments
That is correct! In There was a discussion first, and the end result was that each track had an issue opened for them. This is the issue for the F# track: exercism/fsharp#197. That means that any mention of topics in the metadata of exercises should be removed (not sure if any depends on them, but it seems unlikely).
I think this is an error, as it should indeed be a |
Oh yeah, that was added in 8d48f55 for #80 long before we had .deprecated files (exercism/DEPRECATED.x-api#140) I can tell you I find no uses of this property in https://github.com/exercism/trackler/search?utf8=%E2%9C%93&q=deprecated - the |
Uh oh!
There was an error while loading. Please reload this page.
A quick survey of
x-common/exercises/*/metadata.yml
files show that...blurb
property.source
property.source_url
property.These are the 7 files with additional properties:
All the atipical properties appear to be related to:
From what I understand, exercise classification became a track-specific
matter. Right?
The
counter
exercise is the only one that has adeprecated
property,while others - and also
counter
- have a.deprecated
file, as describedin exercism/DEPRECATED.x-api#140:
Is there any reason to keep these atipical properties in
metadata.yaml
?My impression is that these properties are not serving any useful purpose
right now and should be deleted to avoid confusion, but I don't know if
there is code depending on these keys somewhere.
I'm also asking because, if the only useful properties are...
blurb
source
source_url
... which are data pertaining the exercises - and not their status or
classification - it may be reasonable to consider merging this information
in
canonical-data.json
.The resulting file would be mandatory, but the test cases would be optional.
There is a draft of this idea presented here.
The text was updated successfully, but these errors were encountered: