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

Make release notes more machine-processable #1834

Open
1 of 2 tasks
shepazon opened this issue Nov 29, 2024 · 1 comment
Open
1 of 2 tasks

Make release notes more machine-processable #1834

shepazon opened this issue Nov 29, 2024 · 1 comment
Labels
feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged.

Comments

@shepazon
Copy link
Contributor

shepazon commented Nov 29, 2024

Describe the feature

The release notes provided for each daily release of the SDK are useful, but would be easier to scrape change details from if each section was wrapped in a <div> block.

This change has only minimal to no utility for the majority of people, but anyone trying to automate or create a script to manage information on changes in releases would find it beneficial -- and this change should in theory take very little time. There wouldn't need to be any visible effect of the change, even.

Use Case

I'm working on a script that will scan the release notes for each day's release and add each change listed to a database for use in other tools I plan to create to help me locate when certain changes were made, compile lists of changes affecting specific services, and so forth.

Currently, scripting is somewhat challenging because there is no structural wrapper around each section of content, which means having to locate sibling <ul> elements and pulling their contents. There are risks in this, especially if the structure of the content shifts slightly over time.

Proposed Solution

By wrapping each section (the <hN> heading element and the <ul> element and its descendants) in a <div> block -- ideally with an identifying class name, like "release-section" -- it becomes safer to pull each section and its contents, by simply scanning the HTML of the release information for <div class="release-section"> blocks, then pulling from it the text contents of the header and each of the <li> blocks corresponding to the details on what changed.

That information, plus the date listed for the release, would go into the database for scanning and processing later.

Other Information

If I could find the code that generates this, I'd make the change myself.

Acknowledgements

  • I may be able to implement this feature request
  • This feature might incur a breaking change
@shepazon shepazon added feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged. labels Nov 29, 2024
@shepazon
Copy link
Contributor Author

shepazon commented Dec 4, 2024

After conversation with @jbelkins, I figured I'd add that even better than this would be if in addition to publishing the notes as currently formatted, the tools could produce a JSON file that's updated with each release to contain all the items changed in that release, with a format like:

"format": 1,
"release1": {
    "date": "releasedate",
    "groupname1": [
        "changedescription1",
        "changedescriptionN"
    ],
    "groupnameN": [
        "changedescription1",
        "changedescriptionN"
    ]
},
"releaseN": {
    "date": "releasedate",
    "groupname1": [
        "changedescription1",
        "changedescriptionN"
    ]
}

First is format an identifying integer value that can be updated whenever the format of the table is changed, in case it's needed in the future.

Actual version data follows. releaseX is the version number of the release (1.0.56, 2.5.0, whatever); releasedate is the date on which the version was released; groupNameX are the name of the change type ("Service Features", etc); and changedescriptionX are the descriptive strings for each change in that group in that version of the SDK.

This JSON could be easily used by tools and scripts to find specific changes or types of change, to quickly reference what changed in a given range of version numbers, and so forth. There are many possible use cases for a JSON file like this, and it hopefully wouldn't take much extra effort to produce it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged.
Projects
None yet
Development

No branches or pull requests

1 participant