> the docs should be rebuilt each time the website is built. Harfbuzz does builds of the site every day at a set time, no reason why we can’t do the same.
I meant as in "updating the docs" on every commit, ofcourse they have to be built everytime with the website, and we can just hardcode the tag of the latest freetype release that they have to be built for. On Wed, 27 Oct, 2021, 12:18 AM Bermler, <freet...@protonmail.com> wrote: > > > Sent from ProtonMail for iOS > > > On Tue, Oct 26, 2021 at 2:43 PM, Anurag Thakur <devanuragtha...@gmail.com> > wrote: > > 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. > > the docs should be rebuilt each time the website is built. Harfbuzz does > builds of the site every day at a set time, no reason why we can’t do the > same. > > 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 😄. > > you are right. This is the way to do it. > > > I will see what I can do about this, maybe this weekend. > > I’ll see what I can do too. We can compare works like we did before :) > > Regards > Anurag > > > > On Tue, 26 Oct, 2021, 11:56 PM Nikhil Ramakrishnan, < > ramakrishnan.nik...@gmail.com> 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 >> > > >
