As those watching the SVN repository are aware, there have been a few changes going on outside the actual AF code. I’m going to run through these quickly.

For those not familiar with the repository layout, the distributable Astrum Futura source code is located (from the svn root) at /trunk/astrumfutura. Back to the topic at hand…

First of all, I’ve added a /documentation subdirectory in trunk. Documentation has always been a problem in QS and earlier in SE. For AF we’re considering a policy of making each developer who makes a change responsible for updating the documentation. How we enforce that is another matter I’ll discuss with my fellow developers.

Documentation is being written in the Docbook XML format and will be versioned in the mentioned documentation directory. To allow future scope for translation efforts, the actual files relevant for the default documentation are stored in /manual/en. The en directory contains a manual.xml file which is basically what determines the layout and contents. Individual pages are stored as separate XML documents in manual/en/module_specs. Common page components and miscellaneous appendixes are stored in manual/en/ref. The remaining directories and files allow the Docbook XML to be processed using xsltproc under linux (or Cygwin on Windows) to generate HTML. Options are open for using Apache fop to generate PDF (not really a concern right now). Directions for generating HTML are included in a README file in the /en subdirectory.

Secondly I have added a /standards subdirectory in trunk. The idea is to determine a final coding standard (see PEAR’s PHP_CodeSniffer) and ensure its adhered to. Might seem like a pretty worthless thing to be doing right now but once the code grows to a point where global file formatting changes are time consuming it will prove its worth. The standard being adopted is adapted largely from the PEAR standard. The main difference is that we’ve adopted a different bracing style (opening brace on new line) and modified a few rules to be either more PHP5 specific, or simply to match the preferred styles of the current developers.

Also added, but not yet utilised for AF specific code is /tests. Since most of the classes we use are already sourced from unit tested libraries like the Zend Framework, Swiftmailer and Quantum Star (that independent game library being segregated to a separate project) this will mainly hold web tests. AF will operate strictly on a REST basis, so all requests are in some way reproducible.

Next to be added (later today) is the /build directory. The core idea here is to automate building a distributable as much as possible. Distributing is often seen as a matter of export/copy/zip. In AF it’s a bit more complicated – we need to run all available tests (including all tests for libraries we are sourcing from non-stable sources like SVN trunk) including web tests, build and copy the documentation to its correct location, check the coding standard is clear of errors (ignore warnings), copy all files to a build directory in the correct locations, and finally create distributable archives for zip, gz and bz2. The distributable code must also be tagged in subversion.

I haven’t decided on a final build process and am currently trying out a few tools. The one I’ll be testing later is Phing (since it’s relatively famliar to an Apache ant user).

Did I miss anything? ;-)