-
Notifications
You must be signed in to change notification settings - Fork 112
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
Fix provisional extension notes in appendices #1113
Conversation
Add a new subsection of the extensions appendix capturing the same information. The autogenerated link in the extension metadata for each provisional extension links to this subsection.
@@ -25,6 +25,22 @@ alphabetically by author ID. | |||
Within each group, extensions are listed in alphabetical order by their | |||
names. | |||
|
|||
|
|||
[[boilerplate-provisional-header]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
N.b. this anchor name is hardwired into the generator script and looks a bit odd in context since Vulkan has an entire 'boilerplate' chapter for stuff like this. It would be a bit tedious to change just for the anchor name, but if the wording of the actual generated notice is inappropriate, I can factor that into the API conventions-specific part of the script along with the anchor name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is worth worrying about, thanks for the heads up though!
This got a weird error inside CI which disappeared when I re-ran it, thankfully. Something about not being able to create a directory that already existed for the specattribs.adoc generated file. Definitely does not happen in my local build but it might be something about make parallelization not having all the right dependencies? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there are no other uses of the provisional_notice.asciidoc
file - and I don't think there should be? - we should just remove it. I'll take care of this in a subsequent PR, though.
The autogenerated metadata for provisional extensions includes a sentence linking to what was previously a dead anchor. The anchor now points to a short subsection at the start of the extensions appendix capturing substantially the same language as the explicitly included provisional_notice.asciidoc in the separate extension documents - it has been rephrased slightly and reads slightly better now, I think.
The explicit includes of provisional_notice.asciidoc have been removed (and also from some extensions that were recently ratified as non-provisional).
N.b. some older extensions that were ratified initially as provisional later had the extension version number bumped and a version commented added to the effect that they were no longer provisional. I don't know if that is really needed when they are ratified as non-provisional without any API changes, but for consistency that might be something you wish to do. It is out of scope for this PR and would require changes to both XML and the extension appendix version notes.
Closes #1106