The thrift website is made up of markdown files with YAML headers and templates, and uses the Apache CMS.
Publishing the staging site is doable through the CMS webgui or via shell command:
% ssh -t people.apache.org publish.pl thrift
More complex changes can be accomplished by checking out the svn tree directly. Commits to that tree will trigger builds of the staging site just as if you had committed them by using the CMS webgui. If you are still pining for a nanoc-like feature to preview your changes before committing them by having a daemon 'watch' your filesystem for edits, you really need to wrap your brain around the CMS's commit early and commit often mantra. In fact source control systems are far more effective at communicating changesets than operating systems are (most of the time), and the CMS's build system is changeset-aware based on the data it receives from svn. So think of committing to the CMS's svn tree for thrift as just a formal way of notifying the CMS of your changes so it can automatically (and efficiently) build them to the staging site, just as if you were working locally with a daemon that watches your filesystem for modifications and builds them.
Remember most of all that markdown is aimed first at foremost at human readers, so try to ensure your source content is easily understood by
Not only will your readers prefer a clean style, it will result in fewer bugs and a more consistent experience with the various markdown parsers deployed by the CMS.
The current release versioning is kept in the YAML DATA section of the global "configuration file" lib/path.pm. Update the following values and then following Updating the Website section below
current_release: "0.10.0" current_release_date: "2017-1-03"
After you have updated any content or added new markdown files you will need to commit them to svn to trigger a CMS build of your changes. After a few seconds have passed your build will be ready for viewing on the staging site. See the previous discussion for the various approaches to publishing your changes to the live site after you have verified they are rendering correctly on the staging site.