freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: freetype.org now hosted on gitlab pages


From: Anurag Thakur
Subject: Re: freetype.org now hosted on gitlab pages
Date: Wed, 27 Oct 2021 00:13:39 +0530

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, <ramakrishnan.nikhil@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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]