Uh... "Using master as the rest certain" makes my spine tingle in a bad way.
Rather than polluting the actual master branch history with a bunch of "maybe this will work..." doc commits, why not have a master_doc branch in the working repository that simply tracks master where you could push experiments, and have a set of automated builds for PDF, epub, html against that branch (perhaps on a more frequent basis)? Then you could fix and potentially rebase bad doc commits before pushing those to the actual master and other branches. On Dec 5, 2013 5:06 PM, "Remington Steed" <[email protected]> wrote: > Hi DIG, > > > > In response to Yamil’s question at the meeting today, I had this idea. > When publishing docs, we could use the master branch as our test version. > If it breaks, it's okay because it's only the dev version of the docs! If > people check the 2.5 version (or other versions) of the docs, they will > still work fine. Then you can fix the dev version, check it the next day, > and then apply your fix to the current docs branches (e.g. 2.5 and 2.4). > > > > So, you should still test AsciiDoc syntax on your own machine (or using > Gist, as explained > here<http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:how-to-contribute-documentation&#quick_start_for_new_contributors>), > then push your contributions to the master docs as the next level of > testing, then finally push your contributions to the other versions of the > docs. > > > > Remington > > > > -- > > Remington Steed > > Electronic Resources Specialist > > Hekman Library, Calvin College > > http://library.calvin.edu/ > > > > _______________________________________________ > OPEN-ILS-DOCUMENTATION mailing list > [email protected] > http://list.georgialibraries.org/mailman/listinfo/open-ils-documentation > >
_______________________________________________ OPEN-ILS-DOCUMENTATION mailing list [email protected] http://list.georgialibraries.org/mailman/listinfo/open-ils-documentation
