I think I've got versioned documentation figured out. Here's how it works:
I took the current version of the allele model and split it off into Version 0.1. I'm not sure whether this version has the best claim to be version 0.1 but we have to draw the line somewhere.
The current master branch is called 'development' on the published site. I figure this can represent whatever our most recent build is, with the caveat that it is likely to be inconsistent at times.
The versions are maintained as separate branches (you'll notice the new 0.1 branch on GitHub). This seems a bit more appropriate than tags, as it allows us to make minor fixes without having to spawn an entirely new version.
The site is made aware of versions through two files: data/versions.yml tracks all the versions available
(note that this must be the same on all versions, meaning we'll have to go back and update it for old versions when we start a new one. If we make a habit of creating new versions I'll automate this). The other file is data/current_version.yml, which is used to indicate the version on the current branch.
I created a small script: lib/build.rb which checks out each of the branches, builds them, and publishes them to the GitHub Pages site. It can be run from the root directory of the documentation by typing 'ruby lib/build.rb' at the command line, and is 'it works on my machine' production ready. Feel free to give it a go if you want to publish, but be ready to roll back to a previous revision if something gets borked.
Let me know if there are any questions. I'll be on vacation in Maine this week, so I'll be slightly out of touch, but I'll check in on e-mail every now and again.
I think I've got versioned documentation figured out. Here's how it works:
Let me know if there are any questions. I'll be on vacation in Maine this week, so I'll be slightly out of touch, but I'll check in on e-mail every now and again.