Closed nate-double-u closed 3 years ago
@squeed @bboreham @dcbw @mccv1r0
We should consider removing the documentation from the original repos to prevent duplication.
Previously we've updated the donor repo READMEs with pointers to the new website, and only merged the docs update PR once we had a MVP stood up.
I'm looking at how to manage documentation versioning - I'm looking at the system that longhorn.io used and think I can modify it to manage the two project's (cni + plugins) separate versions tracks.
Please correct me if I'm wrong here, but I recall hearing that plugins may also be individually versioned? If that's true, it may be harder to implement that side of the docs versioning as it only looks like GitHub is tracking the project level versions (https://github.com/longhorn/website/blob/master/config.toml#L17). Is this true, or is there actually only 2 versions to track like I originally thought: CNI releases, and Plugins releases - at the project level)
Paraphrasing from the 2020-10-21 CNI Meeting Minutes:
Latest deploy previews:
Nate knows that Plugins need versioning, however:
Do Plugins need individual versioning?
Does CNI content need versioning?
Spec
and Conventions
files.Do Plugins and CNI documents have the potential for cross-reference?
Docs organization: what of the CNI repo needs to be brought over for the website?
Note that the primary audience will be visiting the website to find Plugins documentation, not necessarily the CNI docs.
Goal for versioning should be to reduce ongoing maintenance
Migrate existing documentation from:
Organize as per cncf/hugo-netlify-starter, keeping in mind that plugins documentation needs to be versioned separately from eachother.