PRDoc new schema

[chevdor]

Overview

This PR brings in the new version of prdoc v0.0.6 and allows:

• local schema
• local config
• local template

It also fixes the existing prdoc files to match the new schema.

todo

• add a brief doc/tldr to help contributors get started
• test CI
• finalize schema
• publish the next prdoc cli version (v0.0.7 or above)

[bkchr]

These should be optional parts of the individual audiences.

[chevdor]

If you are talking about the rendering, this is OK, it will be done in the templates and we can define what audiences will see the migration_db info. That can be done for one or several audiences.

If you refer to moving migration_db inside a specific or multiple audiences in the schema, that will not be very DRY and require providing this information duplicated in some cases.
It is also much easier when editing the prdoc to provide this property close to the top level than down some audiences and have users remember which audience(s) accepts this property.

[bkchr]

What will you do with this information that there is a db migration?

A proper prdoc would mention this migration in the proper audience any way to tell the user that it is there. If you only want this for some kind of filtering, fine. However then just add it as optional fields to audience and just a bool to indicate that there is either a db migration or a runtime migration.

[chevdor]

The prdoc just holds the information, it does not know how we use it. The prdoc file does notthing.

During the release, all the prdoc files involved in the release will be fed into one or more templates (tbd).
Those will define what we actually do with the informations.

For the example with migration_db, this will be shown to some audiences.
@kianenigma gave some more examples here. For the migration_db, the information will be shown to the Runtime dev only.

[bkchr]

Same.

[chevdor]

Same comment than for the migration_db .

What could be done however if that makes it easier is to not have db and runtime embeded under a migrations section but leave it flat. It may be even easier this way.

So instead of:

migrations:
   db: []
   runtime: []

we could have:

db_migrations: []
runtime_migrations: []

[chevdor]

@bkchr is the current schema in an acceptable state to get started ?

[bkchr]

doc:
  - audience: Node Dev
    description: |
      ...
    db_migration: true
    runtime_migration: true
    host_function: true

db_migration, runtime_migration and host_function should be optional. It makes no sense to have them on the "global" level or then somewhere else decide to which audience we want to show these. I also only see these as "information" for further tooling, because I would already expect that the Runtime Dev description mentions the migration and how to use it etc. So, these extra fields are just for better machine processing of these information.

[bkchr]

@chevdor then please remove the semver field and I will approve it.

[chevdor]

Ok, I removed the semver field and fixed the existing prdocs.

[the-right-joyce]

wen merge?

[mrcnski]

Is it intended that there is no "Validator" option? We would just choose "Node Operator" for that case?

[bkchr]

Yes. Most of the changes are equally for both groups and normal node operators are also able to just skip the one validator message for every 5th release.

[mutantcornholio]

🔥