feat: add releaselist schemas into schemas.json. #1269
Conversation
sbillinge
left a comment
sbillinge
left a comment
There was a problem hiding this comment.
this schema is not quite right I think. Honestly, it would be easier if you wrote the exemplar before we write the schema, and we can the write the schema to capture the exemplar.
| "required": false, | ||
| "anyof_type": ["date", "string"] | ||
| }, | ||
| "day": { |
There was a problem hiding this comment.
day/month/year are probably not needed. these are replaced more recently by date. They are still needed if only a partial date is know, butI think every release will have a well defined date.
| "required": false, | ||
| "type": "integer" | ||
| }, | ||
| "released_package": { |
There was a problem hiding this comment.
shall we call this "releases"?
| "schema": { | ||
| "type": "dict", | ||
| "schema": { | ||
| "package_name": { |
There was a problem hiding this comment.
isn't the package already known from the top level?
OK, I would first design the exemplar instead and then redo the schemas. |
| "releaseReports": [ | ||
| { | ||
| "_id": "sbillinge", | ||
| "date": "17/07/2025", |
There was a problem hiding this comment.
dates are in iso standard. Also, what date is this?, when the package was first created? in which case creation_date or something like that.
| "year": 2020 | ||
| } | ||
| ], | ||
| "releaseReports": [ |
There was a problem hiding this comment.
I think this collection should be called software
There was a problem hiding this comment.
But I see that in schemas.json there is a collection called software created by last year for this. Maybe we should base on that to further develop the release and release_type?
There was a problem hiding this comment.
Yes, I forgot about that... We Should use that as a start
| ], | ||
| "releaseReports": [ | ||
| { | ||
| "_id": "sbillinge", |
There was a problem hiding this comment.
I would expect the id to reflect the name of the software
| "date": "17/07/2025", | ||
| "releases": [ | ||
| { | ||
| "package_name": "regolith", |
There was a problem hiding this comment.
this should be at the top level, not in the release.
| "releases": [ | ||
| { | ||
| "package_name": "regolith", | ||
| "description": "A Group Content Management System", |
| "package_name": "regolith", | ||
| "description": "A Group Content Management System", | ||
| "url": "https://github.com/regro/regolith", | ||
| "release_updates": [ |
| "change name and then fix tests for function that formats awards and honors"], | ||
| "release_url": "https://github.com/regro/regolith/releases/tag/0.9.1", | ||
| "release_date": "21/07/2024", | ||
| "author": ["Simon Billinge", "Rundong Hua"], |
There was a problem hiding this comment.
not needed in the release, but at the top level we may need authors and have it take the ids
| "release_url": "https://github.com/regro/regolith/releases/tag/0.9.1", | ||
| "release_date": "21/07/2024", | ||
| "author": ["Simon Billinge", "Rundong Hua"], | ||
| "author_id": ["sbillinge", "stevenhua0320"] |
| "version_number": "0.9.1", | ||
| "updated_capacities": ["Rearrange Regolith package to new Billingegroup package standards", | ||
| "change name and then fix tests for function that formats awards and honors"], | ||
| "release_url": "https://github.com/regro/regolith/releases/tag/0.9.1", |
There was a problem hiding this comment.
maybe keep this if we can use it get the release info. In which case, don't save the other information here, for example the changelog.
Maybe have a release_type that can be major, minor, patch. This will allow us to chosse what levels of release we want to list in some situation.
|
Closes thisw as we need to build on |
2 participants
@sbillinge Ready to review the potential schemas for releaselist. The Tests on PR fails now because I have not create the corresponding exemplars in
exemplars.json. After we reach an agreement on the schemas, I would create the corresponding exemplar.