Merge pull request #198 from jhollingworth/versioning

Version v0.8 docs

Makefile

@@ -32,8 +32,11 @@ build: lint
 	@cat dist/marty.js | $(BIN)/uglifyjs > dist/marty.min.js
 	@gzip dist/marty.min.js -c > dist/marty.min.js.gz
 
-docs: bootstrap-ruby
+docs:
 	@cd docs && bundle exec jekyll serve -w
 
 release-docs: bootstrap-ruby
-	@cd docs && bundle exec rake release
+	@sh ./build/release-docs.sh
+
+prerelease-docs:
+	@sh ./build/prerelease-docs.sh

VERSION

@@ -0,0 +1 @@
+0.8.15

build/prerelease-docs.sh

@@ -0,0 +1,6 @@
+version=$(cat VERSION)
+
+cd docs
+VERSION=true jekyll build -d ../../marty-gh-pages/v/$version
+
+cd ..

build/release-docs.sh

@@ -0,0 +1,19 @@
+version=$(cat VERSION)
+
+mkdir -p tmp/doc-versions
+
+#Copy the old versions of documentation for now
+cp -r ../marty-gh-pages/v/ tmp/doc-versions
+
+cd docs
+
+jekyll build -d ../../marty-gh-pages
+echo martyjs.org > ../../CNAME
+
+# Copy the old versions back again
+cp -r ../tmp/doc-versions/* ../../marty-gh-pages/v/
+rm -rf ../tmp/doc-versions
+
+VERSION=true jekyll build -d ../../marty-gh-pages/v/$version
+
+cd ..

docs/Gemfile.lock

@@ -4,18 +4,18 @@ GEM
     blankslate (2.1.2.4)
     celluloid (0.16.0)
       timers (~> 4.0.0)
-    classifier-reborn (2.0.2)
+    classifier-reborn (2.0.3)
       fast-stemmer (~> 1.0)
     coffee-script (2.3.0)
       coffee-script-source
       execjs
-    coffee-script-source (1.8.0)
+    coffee-script-source (1.9.1)
     colorator (0.1)
-    execjs (2.2.2)
+    execjs (2.4.0)
     fast-stemmer (1.0.2)
-    ffi (1.9.6)
+    ffi (1.9.8)
     hitimes (1.2.2)
-    jekyll (2.5.0)
+    jekyll (2.5.3)
       classifier-reborn (~> 2.0)
       colorator (~> 0.1)
       jekyll-coffeescript (~> 1.0)
@@ -34,42 +34,42 @@ GEM
       coffee-script (~> 2.2)
     jekyll-gist (1.1.0)
     jekyll-paginate (1.1.0)
-    jekyll-sass-converter (1.2.1)
+    jekyll-sass-converter (1.3.0)
       sass (~> 3.2)
-    jekyll-watch (1.1.2)
+    jekyll-watch (1.2.1)
       listen (~> 2.7)
-    json (1.8.1)
-    kramdown (1.5.0)
-    liquid (2.6.1)
-    listen (2.7.11)
+    json (1.8.2)
+    kramdown (1.6.0)
+    liquid (2.6.2)
+    listen (2.9.0)
       celluloid (>= 0.15.2)
       rb-fsevent (>= 0.9.3)
       rb-inotify (>= 0.9)
-    mercenary (0.3.4)
-    mini_portile (0.6.1)
-    nokogiri (1.6.4.1)
+    mercenary (0.3.5)
+    mini_portile (0.6.2)
+    nokogiri (1.6.6.2)
       mini_portile (~> 0.6.0)
     parslet (1.5.0)
       blankslate (~> 2.0)
-    posix-spawn (0.3.9)
-    pygments.rb (0.6.0)
+    posix-spawn (0.3.10)
+    pygments.rb (0.6.2)
       posix-spawn (~> 0.3.6)
-      yajl-ruby (~> 1.1.0)
-    rake (10.3.2)
+      yajl-ruby (~> 1.2.0)
+    rake (10.4.2)
     rb-fsevent (0.9.4)
     rb-inotify (0.9.5)
       ffi (>= 0.5.0)
-    redcarpet (3.2.0)
-    rouge (1.7.2)
+    redcarpet (3.2.2)
+    rouge (1.8.0)
     safe_yaml (1.0.4)
     sanitize (2.1.0)
       nokogiri (>= 1.4.4)
-    sass (3.4.7)
+    sass (3.4.13)
     timers (4.0.1)
       hitimes
     toml (0.1.2)
       parslet (~> 1.5.0)
-    yajl-ruby (1.1.0)
+    yajl-ruby (1.2.1)
 
 PLATFORMS
   ruby

docs/Rakefile

@@ -14,4 +14,11 @@ end
 task :release => [:update_version] do
   system "jekyll build -d ../../marty-gh-pages"
   File.open('../../marty-gh-pages/CNAME', 'w+') { |f| f.write('martyjs.org') }
+end
+
+task :release_version => [:update_version] do
+  site_config = YAML.load_file('_config.yml')
+
+  system "jekyll build -d ../../marty-gh-pages/v/#{site_config['current_version']}"
+  File.open('../../marty-gh-pages/CNAME', 'w+') { |f| f.write('martyjs.org') }
 end

docs/_api/action-creators/index.md

@@ -26,6 +26,6 @@ An (optional) display name for the action creator. Used for richer debugging.
 
 <h2 id="dispatch">dispatch([...])</h2>
 
-Dispatches an action payload. Any [action handlers](/api/stores/index.html#handleAction) will be invoked with the given action handlers.
+Dispatches an action payload. Any [action handlers]({% url /api/stores/index.html#handleAction %}) will be invoked with the given action handlers.
 
 Returns <code>Action</code>. You can rollback an action by calling <code>action.rollback()</code>.

docs/_api/state-mixin/index.md

@@ -8,7 +8,7 @@ section: State Mixin
 
 <h3 id="listenTo">listenTo</h3>
 
-Expects either a [store](/api/stores/index.html) or an array of [stores](/api/stores/index.html). Just before the [initial render](http://facebook.github.io/react/docs/component-specs.html#mounting-componentwillmount), it will register a change listener with the specified store(s).
+Expects either a [store]({% url /api/stores/index.html %}) or an array of [stores]({% url /api/stores/index.html %}). Just before the [initial render](http://facebook.github.io/react/docs/component-specs.html#mounting-componentwillmount), it will register a change listener with the specified store(s).
 
 When the element is about to be [unmounted from the DOM](http://facebook.github.io/react/docs/component-specs.html#unmounting-componentwillunmount) it will dispose of an change listeners.
 
@@ -38,7 +38,7 @@ var UserState = Marty.createStateMixin({
 
 <h3 id="stores">Stores</h3>
 
-If the value of a key is a [store](/api/stores/index.html), then the mixin will automatically listen to the store and merge the stores state with result of <code>getState</code>
+If the value of a key is a [store]({% url /api/stores/index.html %}), then the mixin will automatically listen to the store and merge the stores state with result of <code>getState</code>
 
 {% highlight js %}
 var UserState = Marty.createStateMixin({

docs/_api/stores/index.md

@@ -33,7 +33,7 @@ An (optional) display name for the store. Used for richer debugging.
 
 The <code>handlers</code> property is used to define which handlers should be called when an action is dispatched. The key is the name of the handler and value is an [action predicate](#action-predicates).
 
-When invoked the handlers arguments are [the arguments passed to the dispatcher](/api/action-creators/index.html#dispatch). The original action is available by calling <code>this.action</code>.
+When invoked the handlers arguments are [the arguments passed to the dispatcher]({% url /api/action-creators/index.html#dispatch %}). The original action is available by calling <code>this.action</code>.
 
 {% highlight js %}
 var UsersStore = Marty.createStore({
@@ -111,7 +111,7 @@ var UsersStore = Marty.createStore({
 
 The state property holds the current state of the store. You can get the state by calling <code>this.state</code> or <code>this.getState()</code>.
 
-If you want to change the state to a new instance (or if you are using [immutable data collections](/guides/stores/immutable-data-collections.html)) you can set the states value or call <code>this.setState(state)</code>
+If you want to change the state to a new instance (or if you are using [immutable data collections]({% url /guides/stores/immutable-data-collections.html %})) you can set the states value or call <code>this.setState(state)</code>
 
 {% highlight js %}
 addUsers: function (users) {

docs/_guides/action-creators/index.md

@@ -7,9 +7,9 @@ section: Action Creators
 
 Action Creators are where any changes to your applications state start. Actions are functions that are responsible for coordinating changes to local and remote state.
 
-All actions have a type of string which gives a terse description of what the action does (e.g. "UPDATE\_USER_EMAIL"). Stores listen for new actions (using the [dispatcher](/guides/dispatcher/index.html)) and use [action's type to determine whether to do something with it](/api/stores/index.html#handlers). Action types help us build loosely coupled applications that can grow without increasing complexity.
+All actions have a type of string which gives a terse description of what the action does (e.g. "UPDATE\_USER_EMAIL"). Stores listen for new actions (using the [dispatcher]({% url /guides/dispatcher/index.html %})) and use [action's type to determine whether to do something with it]({% url /api/stores/index.html#handlers %}). Action types help us build loosely coupled applications that can grow without increasing complexity.
 
-[Constants](/guides/constants/index.html) provide a simple way of creating action creators for a type
+[Constants]({% url /guides/constants/index.html %}) provide a simple way of creating action creators for a type
 
 {% highlight js %}
 var UserConstants = Marty.createConstants(["UPDATE_EMAIL"]);

docs/_guides/action-creators/source-action-creators.md

@@ -5,7 +5,7 @@ id: server-action-creators
 section: Action Creators
 ---
 
-Often your action creator will call a [state source](/guides/state-source/index.html) which then calls another action creator with the response. This becomes a problem if you are using a module loader (e.g. CommonJS, AMD) since it creates a cyclic dependency.
+Often your action creator will call a [state source]({% url /guides/state-source/index.html %}) which then calls another action creator with the response. This becomes a problem if you are using a module loader (e.g. CommonJS, AMD) since it creates a cyclic dependency.
 
 The way to get around this is to have a seperate action creator that is responsible for handling responses from sources. In Marty we call them **Source Action Creator**.
 

docs/_guides/constants/index.md

@@ -5,7 +5,7 @@ id: constants
 section: Constants
 ---
 
-[Actions](/guides/action-creators/index.html) must have a type which is a terse description of what the action does (e.g. ``"DELETE_USER"``). The main purpose of action types is that they allow you to loosely couple your actions to your stores ([Law of Demeter](http://en.wikipedia.org/wiki/Law_of_Demeter)).
+[Actions]({% url /guides/action-creators/index.html %}) must have a type which is a terse description of what the action does (e.g. ``"DELETE_USER"``). The main purpose of action types is that they allow you to loosely couple your actions to your stores ([Law of Demeter](http://en.wikipedia.org/wiki/Law_of_Demeter)).
 
 As your application grows you might find that it becomes littered with these strings, making it difficult to refactor and understand at a high level what actions are available. Marty provides **Constants** as a solution to this problem.
 

docs/_guides/dispatcher/index.md

@@ -5,7 +5,7 @@ id: dispatcher
 section: Dispatcher
 ---
 
-The dispatcher is the central hub in which all application data flows throw. When a store is created it [registers](http://facebook.github.io/flux/docs/dispatcher.html#api) a callback with the dispatcher. Whenever an [action creator](/guides/action-creators/index.html) creates an action and you call ``this.dispatch()``, the action will be passed to the dispatcher, which passes it to any registered stores. The dispatcher will call each registered callback synchronously. Any actions that are dispatched during this process will be queued until all callbacks are called.
+The dispatcher is the central hub in which all application data flows throw. When a store is created it [registers](http://facebook.github.io/flux/docs/dispatcher.html#api) a callback with the dispatcher. Whenever an [action creator]({% url /guides/action-creators/index.html %}) creates an action and you call ``this.dispatch()``, the action will be passed to the dispatcher, which passes it to any registered stores. The dispatcher will call each registered callback synchronously. Any actions that are dispatched during this process will be queued until all callbacks are called.
 
 Marty uses [facebook's dispatcher](https://github.com/facebook/flux/).
 
@@ -19,7 +19,7 @@ var dispatchToken = Dispatcher.register(function (action) {
 Dispatcher.dispatch({ type: 'CREATE_FOO' });
 {% endhighlight %}
 
-Normally [action creators](/guides/action-creators/index.html) are responsible for calling the dispatcher. However if you feel the need to dispatch an action elsewhere, Marty expects the dispatch payload to be an instance of [``ActionPayload``](https://github.com/jhollingworth/marty/blob/master/lib/actionPayload.js).
+Normally [action creators]({% url /guides/action-creators/index.html %}) are responsible for calling the dispatcher. However if you feel the need to dispatch an action elsewhere, Marty expects the dispatch payload to be an instance of [``ActionPayload``](https://github.com/jhollingworth/marty/blob/master/lib/actionPayload.js).
 
 {% highlight js %}
 var Dispatcher = require('marty/dispatcher');

docs/_guides/flux/index.md

@@ -9,11 +9,11 @@ State is a big problem in the UI. Most JS applications have few restrictions on
 
 Flux is an answer to that problem. At its most basic level it's a set of rules about how to manage your applications state. Specifically who can change it, where they can change it and in what direction those changes should be propagated through your application.
 
-There are 4 things you will need to understand: How to tell the application to change its state ([Action creators](/guides/action-creators/index.html)), How to change the applications state ([Stores](/guides/stores/index.html)), how to tell the view that the state has changed ([State mixins](/guides/state-mixin/index.html)) and how to tie them all together ([Constants](/guides/constants/index.html)).
+There are 4 things you will need to understand: How to tell the application to change its state ([Action creators]({% url /guides/action-creators/index.html %})), How to change the applications state ([Stores]({% url /guides/stores/index.html %})), how to tell the view that the state has changed ([State mixins]({% url /guides/state-mixin/index.html %})) and how to tie them all together ([Constants]({% url /guides/constants/index.html %})).
 
 Action Creators are where any changes to your applications state starts. Actions are functions that are responsible for coordinating changes to local and remote state. Actions have a type which is a string describing the action (e.g. "UPDATE\_USER_EMAIL").
 
-We want to be explicit about the action types in your application so we define them as ([Constants](/guides/constants/index.html)). Constants allow you to loosely couple your application as well as documenting what actions are available (Useful for understanding what your application can do). Constants are also responsible for creating action creators.
+We want to be explicit about the action types in your application so we define them as ([Constants]({% url /guides/constants/index.html %})). Constants allow you to loosely couple your application as well as documenting what actions are available (Useful for understanding what your application can do). Constants are also responsible for creating action creators.
 
 {% highlight js %}
 var UserConstants = Marty.createConstants(["UPDATE_USER_EMAIL"]);
@@ -63,7 +63,7 @@ var UserStore = Marty.createStore({
 });
 {% endhighlight %}
 
-When your application starts, each store automatically starts listening to the dispatcher. When an action is dispatched, each store checks its [``handlers`` hash](/api/stores/index.html#handlers) to see if the store has a handler for the actions type. If it does it will call that handler, passing in the actions data. The action handler then updates its internal state (all stored in ``this.state``).
+When your application starts, each store automatically starts listening to the dispatcher. When an action is dispatched, each store checks its [``handlers`` hash]({% url /api/stores/index.html#handlers %}) to see if the store has a handler for the actions type. If it does it will call that handler, passing in the actions data. The action handler then updates its internal state (all stored in ``this.state``).
 
 The next (and final) step is to notify views about the new data. Like the dispatcher, you can register to be notified of any changes to a store.
 
@@ -109,7 +109,7 @@ var User = React.createClass({
 });
 {% endhighlight %}
 
-As your application grows you start to find that there is a lot of boilerplate code to get views to listen to stores. [State mixins](/guides/state-mixin/index.html) are our solution to this problem. State mixins manage listening to stores for you as well as providing a simpler API to implement:
+As your application grows you start to find that there is a lot of boilerplate code to get views to listen to stores. [State mixins]({% url /guides/state-mixin/index.html %}) are our solution to this problem. State mixins manage listening to stores for you as well as providing a simpler API to implement:
 
 {% highlight js %}
 var UserStateMixin = Marty.createStateMixin({
@@ -139,10 +139,10 @@ var User = React.createClass({
 });
 {% endhighlight %}
 
-Whenever you want to change a value within your application, your data must follow this flow of [Action creator](/guides/action-creators/index.html) **->** [Dispatcher](/guides/dispatcher/index.html) **->** [Store](/guides/stores/index.html) **->** [State mixin](/guides/state-mixin/index.html) **->** View. This is known as a **unidirectional data flow**.
+Whenever you want to change a value within your application, your data must follow this flow of [Action creator]({% url /guides/action-creators/index.html %}) **->** [Dispatcher]({% url /guides/dispatcher/index.html %}) **->** [Store]({% url /guides/stores/index.html %}) **->** [State mixin]({% url /guides/state-mixin/index.html %}) **->** View. This is known as a **unidirectional data flow**.
 
 <center>
   <img src="/img/data-flow.png" alt="Data flow"/>
 </center>
 
-While this seems superfluous at first, it turns out to have some great benefits. First and foremost, it's really easy to debug. There's only one place your application state can change so you don't have to dig into all the views to work out where a value was changed (it's even easier if you're using [immutable data collections](/guides/stores/immutable-data-collections.html)). Thanks to action types being strings you have a loosely coupled [Law of Demeter](http://en.wikipedia.org/wiki/Law_of_Demeter) architecture which is easy to grow without increasing the complexity of the code base.
+While this seems superfluous at first, it turns out to have some great benefits. First and foremost, it's really easy to debug. There's only one place your application state can change so you don't have to dig into all the views to work out where a value was changed (it's even easier if you're using [immutable data collections]({% url /guides/stores/immutable-data-collections.html %})). Thanks to action types being strings you have a loosely coupled [Law of Demeter](http://en.wikipedia.org/wiki/Law_of_Demeter) architecture which is easy to grow without increasing the complexity of the code base.

docs/_guides/getting-started/index.md

@@ -5,7 +5,7 @@ id: getting-started
 section: Getting Started
 ---
 
-Welcome to Marty! This guide will help you learn how to use it. If you've never heard of Flux before I suggest you read an [overview of Flux](/guides/flux). Or if you prefer you can look at some examples:
+Welcome to Marty! This guide will help you learn how to use it. If you've never heard of Flux before I suggest you read an [overview of Flux]({% url /guides/flux %}). Or if you prefer you can look at some examples:
 
 * [Marty Todo MVC](https://github.com/jhollingworth/marty-todo-mvc)
 * [Marty Chat Example](https://github.com/jhollingworth/marty-chat-example)

docs/_guides/state-mixin/index.md

@@ -5,9 +5,9 @@ id: state-mixin
 section: State Mixin
 ---
 
-We found that there was a lot of boilerplate code in React components to start listening to [stores](/guides/stores/index.html) and get their states. The State mixin helps to reduce the amount of code you have to write.
+We found that there was a lot of boilerplate code in React components to start listening to [stores]({% url /guides/stores/index.html %}) and get their states. The State mixin helps to reduce the amount of code you have to write.
 
-Firstly, it automatically [adds change listeners](/api/stores/index.html#addChangeListener) to [stores you want to listen to](/api/state-mixin/index.html#listenTo), as well as disposing of those listeners when the component unmounts.
+Firstly, it automatically [adds change listeners]({% url /api/stores/index.html#addChangeListener %}) to [stores you want to listen to]({% url /api/state-mixin/index.html#listenTo %}), as well as disposing of those listeners when the component unmounts.
 
 It also introduces a new function [<code>getState</code>](#getState), which returns the state of the component. It will be called just before the initial render of the component and whenever a store updates.