Thanks for the references Nikhil, I am sure they will be helpful😊. > not a good idea unless we maintain multiple copies of the docs
Hmm, you have a point. It's not really necessary to update docs on each commit, maybe we can mark the new APIs as in-progress and add a switch to show only released APIs, but that's a future problem. However the main point was that storing the freetype2/docs/ in the freetype-web repo is unnecessary, we can simply configure a CI job to deploy the API reference website whenever we need to change it, and Alexei doesn't have to worry about changes to those files 😄. I will see what I can do about this, maybe this weekend. Regards Anurag On Tue, 26 Oct, 2021, 11:56 PM Nikhil Ramakrishnan, < [email protected]> wrote: > Hi all, > > I want to quickly point to existing resources that could be of any help: > > I think this was already mentioned in one of the threads: This repository > > https://github.com/nikramakrishnan/freetype-web-jekyll > > (and the published site at > https://nikramakrishnan.github.io/freetype-web-jekyll/) > > has some of the pages already converted to Markdown, and uses Jekyll > to build the static site. I had done some additional customizations to > carry over some features from the existing site (like specifying the > blue/green theme for the page) as well, but I'm not sure if that is of > any use if the plan is to have a different build system for the site. > > > Also, some comments: > > > Come to think of it, if the API reference webpages can be completely > autogenerated we don't need to store their source in the freetype-web repo, > we can just create a CI job in the main freetype repo that will update the > website with the latest content from docwriter on every update to master. > > The docs are built for each version before release and reflect the API > reference as of that version. Building docs from master means having > stuff in the reference that may or may not be a part of the latest > release and is generally not a good idea unless we maintain multiple > copies of the docs that specify the version number (or master, for the > latest built docs). > > > But when the library source changes we would need to update the contents > of that folder with the latest from docwriter, right? > > Yes and no. The updates happen at each release. > > However, the CI stuff is a good idea. If Werner is open to this, we > can probably automate part (or whole, eventually) of the release > process by automatically building the API reference (along with other > 'release' actions) when a new release is tagged on the repo. > > > Nikhil >
