Merge remote-tracking branch 'origin/master'
diff --git a/README.md b/README.md
index 79dfaa4..f53e743 100644
--- a/README.md
+++ b/README.md
@@ -29,7 +29,7 @@
This in turn requires Ruby and gems as described in the `Gemfile`:
install [RVM](http://rvm.io/) to manage Ruby installations and sets of Ruby gems.
- \curl -sSL https://get.rvm.io | bash -s stable --auto-dotfiles
+ curl -sSL https://get.rvm.io | bash -s stable --auto-dotfiles
Close your shell session and start a new one, to get the new
environment that RVM has configured. Change directory to the location where
diff --git a/_build/build.sh b/_build/build.sh
index a51d984..b04debf 100755
--- a/_build/build.sh
+++ b/_build/build.sh
@@ -22,7 +22,7 @@
echo "* website-root : to build the website only, in the root"
echo "* guide-latest : to build the guide only, in /v/latest/"
# BROOKLYN_VERSION_BELOW
- echo "* guide-version : to build the guide only, in the versioned namespace /v/1.1.0-SNAPSHOT/"
+ echo "* guide-version : to build the guide only, in the versioned namespace /v/1.2.0-SNAPSHOT/"
echo "* test-guide-root : to build the guide only, in the root (for testing)"
echo "* test-both-sub : to build the website to /sub/ and guide to /sub/v/latest/ (for testing)"
echo "* original : to build the files in their original location (website it /website and guide in /guide/, for testing)"
@@ -74,7 +74,7 @@
# Mac bash defaults to v3 not v4, so can't use assoc arrays :(
DIRS_TO_MOVE[0]=guide
# BROOKLYN_VERSION_BELOW
- DIRS_TO_MOVE_TARGET[0]=v/1.1.0-SNAPSHOT
+ DIRS_TO_MOVE_TARGET[0]=v/1.2.0-SNAPSHOT
DIRS_TO_MOVE[1]=style
STYLE_SUBDIR=${DIRS_TO_MOVE_TARGET[0]}/style
DIRS_TO_MOVE_TARGET[1]=$STYLE_SUBDIR
diff --git a/_build/config-guide-version.yml b/_build/config-guide-version.yml
index e4be68d..331f458 100644
--- a/_build/config-guide-version.yml
+++ b/_build/config-guide-version.yml
@@ -1,6 +1,6 @@
path:
# BROOKLYN_VERSION_BELOW
- guide: /v/1.1.0-SNAPSHOT
+ guide: /v/1.2.0-SNAPSHOT
# BROOKLYN_VERSION_BELOW
- style: /v/1.1.0-SNAPSHOT/style
+ style: /v/1.2.0-SNAPSHOT/style
website: ""
diff --git a/_build/javadoc-overview.html b/_build/javadoc-overview.html
index 4add25b..eaf7e39 100644
--- a/_build/javadoc-overview.html
+++ b/_build/javadoc-overview.html
@@ -1,7 +1,7 @@
<html><body>
<!-- BROOKLYN_VERSION_BELOW -->
-Javadoc for <a href="http://brooklyn.io"> Apache Brooklyn</a> 1.1.0-SNAPSHOT
+Javadoc for <a href="http://brooklyn.io"> Apache Brooklyn</a> 1.2.0-SNAPSHOT
<p>
Apache Brooklyn is distributed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License v2.0</a>.
@@ -9,7 +9,7 @@
<p>
<!-- BROOKLYN_VERSION_BELOW -->
-This is the Javadoc for v 1.1.0-SNAPSHOT (git SHA1 hash ${SHA1STAMP}) auto-generated on ${DATESTAMP}.
+This is the Javadoc for v 1.2.0-SNAPSHOT (git SHA1 hash ${SHA1STAMP}) auto-generated on ${DATESTAMP}.
</p>
</body><html>
diff --git a/_config.yml b/_config.yml
index 930f7a2..4f93f65 100644
--- a/_config.yml
+++ b/_config.yml
@@ -65,7 +65,7 @@
'/guide' : '/v/0.12.0'
'/website' : ''
-brooklyn-version: 1.1.0-SNAPSHOT # BROOKLYN_VERSION brooklyn-docs-version
+brooklyn-version: 1.2.0-SNAPSHOT # BROOKLYN_VERSION brooklyn-docs-version
brooklyn-snapshot-git-branch: master # if line above is SNAPSHOT this should point to corresponding git branch (e.g. master, 0.4)
# This is auto-detected, but you can override it if needed.
diff --git a/_extra/simple_java_examples/examples.md b/_extra/simple_java_examples/examples.md
index 353e1b4..e20284f 100644
--- a/_extra/simple_java_examples/examples.md
+++ b/_extra/simple_java_examples/examples.md
@@ -22,7 +22,7 @@
<dependency>
<groupId>io.brooklyn</groupId>
<artifactId>brooklyn-all</artifactId>
- <version>1.1.0-SNAPSHOT</version> <!-- BROOKLYN_VERSION -->
+ <version>1.2.0-SNAPSHOT</version> <!-- BROOKLYN_VERSION -->
</dependency>
</dependencies>
diff --git a/_plugins/brooklyn_metadata.rb b/_plugins/brooklyn_metadata.rb
index 77ea79f..9b40b5a 100644
--- a/_plugins/brooklyn_metadata.rb
+++ b/_plugins/brooklyn_metadata.rb
@@ -7,7 +7,7 @@
#
module BrooklynMetadata
- BROOKLYN_VERSION = "1.1.0-SNAPSHOT" unless defined? BROOKLYN_VERSION
+ BROOKLYN_VERSION = "1.2.0-SNAPSHOT" unless defined? BROOKLYN_VERSION
class Generator < Jekyll::Generator
def generate(site)
diff --git a/_plugins/read.rb b/_plugins/read.rb
index df0a26a..c0faf57 100644
--- a/_plugins/read.rb
+++ b/_plugins/read.rb
@@ -45,7 +45,7 @@
# is there a better way to trim a leading / ?
file = file.relative_path_from(Pathname.new("/")) unless file.relative?
- raise "No such file #{file} in read call (from #{context.dig('page','path')})" unless file.exist?
+ raise "No such file #{file} in read call (from #{context_page['path']})" unless file.exist?
file
end
diff --git a/guide/blueprints/workflow/common.md b/guide/blueprints/workflow/common.md
index 6add635..66426f1 100644
--- a/guide/blueprints/workflow/common.md
+++ b/guide/blueprints/workflow/common.md
@@ -93,6 +93,9 @@
Apart from `name` and `id` above, if a step's `condition` is unmet,
the other properties set on a step are ignored.
+The `if` step can be used for simple conditions, as shown in the next section.
+
+
### Jumping with "Next" or "Goto"
The common property `next` allows overriding the workflow sequencing,
@@ -117,6 +120,21 @@
in a proper high-level programming language, consider putting that program
into a container and calling it from your workflow.
+Thus the above workflow can be written more concisely as:
+
+```
+steps:
+- if ${scratch.skip_date} then goto skipping-ssh-date
+
+- step: ssh echo today is `date`
+ next: end
+
+- id: skipping-ssh-date
+ name: Not doing SSH
+ step: log skipping ssh date command
+```
+
+
### Input and Output
Most steps take input parameters and return output.
diff --git a/guide/blueprints/workflow/nested-workflow.md b/guide/blueprints/workflow/nested-workflow.md
index 1919158..c8c8eed 100644
--- a/guide/blueprints/workflow/nested-workflow.md
+++ b/guide/blueprints/workflow/nested-workflow.md
@@ -60,22 +60,92 @@
Where a list is supplied, the result of the step is the list collecting the output of each sub-workflow.
-If a `condition` is supplied when a list is being used, the `workflow` step will always run,
-and the `condition` will be applied to entries in the list.
-An example of this is included below.
+If a `condition` is supplied when a list is being used,
+that `condition` is applied to each entry in the list.
+The `workflow` step itself will always appear to run, but might have 0 nested workflows,
+and in that case will return the empty list.
+If the condition is intended to block the list from being evaluated,
+and should be evaluated in the containing workflow's scope,
+consider using a `subworkflow` with the outer condition containing the `workflow`.
+An example of this is included below, using `service.isUp` with `children`.
+
+### Associated Step Types
The `foreach` type is a simplified variant of `workflow` when recursing over a list,
-taking the same.
+taking the same arguments as `workflow` but supporting a shorthand syntax where
+the `target_var_name` and `target` can be specified as in `foreach VAR_NAME in TARGET`.
+A single step can be supplied as `do STEP` at the end;
+either that or `steps` is required (but not both),
+and that step or those steps are run for all items in the target list.
+
+The `subworkflow` type is another simplified variant that does not allow any target
+(so no recursing over a list and no concurrency), and which -- unlike the other workflow step types --
+shares variables with the calling workflow. All variables from the immediate containing workflow
+can be accessed and updated in a `subworkflow`, and new variables defined in the `subworkflow`
+are subsequently available in the outer workflow. The `steps` are required/
+A `name` is frequently given for readability, as are `condition` or `on-error` entries
+to apply a condition or error-handler to the block of steps.
+If no step type is defined, but `steps` are defined, this `subworkflow` step type is assumed.
+
+The `if` type acts like `subworkflow` but allows specifying a condition in shorthand.
+
#### Example
```
+- foreach x in 1..3 do return ${x}
+```
+
+The above loop will return `[1,2,3]` and proceed to the next step.
+
+```
+# foreach, nested workflow
- step: foreach x in 1..3
steps:
+ - let x = ${x} + 1
- return ${x}
```
-The above loop will return `[1,2,3]`.
+The above loop will return `[2,3,4]` and proceed to the next step.
+It is the same as the previous except it is supplying multiple steps
+to run on each iteration.
+Note that the assignment to `${x}` does not side-effect the loop,
+and nor is it available to the outer workflow, when using `foreach` or `workflow`.
+Use `${output}` to access the result,
+and see the `reducing` section below.
+
+```
+# subworkflow
+- let x = 1
+- steps:
+ - let x = ${x} + 1
+ - return ${x}
+- let x = Not run, but if it were it could access ${x}
+```
+
+The above implicit lightweight subworkflow _does_ run in the parent workflow's context,
+so it will access and update the same instance of `${x}`,
+and it will `return` from the workflow, not running the next step.
+
+```
+# if
+- let x = 1
+- if ${x} == 1 then let x = ${x} + 1
+- return ${x}
+```
+
+The above `if` step can access and update outer variables, like `subworkflow`, providing a convenient shorthand for simple conditions and steps. It is functionally identical to this:
+
+```
+- let x = 1
+- condition:
+ target: ${x}
+ equals: 1
+ steps:
+ - let x = ${x} + 1
+- return ${x}
+```
+
### Reducing
@@ -85,17 +155,19 @@
Where it is desired to share variables across iterations, the key `reducing` can be supplied,
giving a map of variable names to be shared and their initial values.
-When `reducing`, the output of the workflow is this set of variables with their final values.
+When `reducing`, the indicated variables are available as scratch workflow variables in the calling workflow.
+
+This cannot be used with `subworkflow`, as all variables are considered reduced in a `subworkflow`,
+and it cannot be used with `concurrency` as that risks race conditions in updating the reduced variables.
+(You can use `inputs` with both to provide new local variables.)
#### Example
```
-- step: foreach x in 1..3
+- step: foreach x in 1..3 do let sum = ${sum} + ${x}
reducing:
sum: 0
- steps:
- - let sum = ${sum} + ${x}
```
The above loop will return `6`.
@@ -137,6 +209,20 @@
- invoke-effector effector-on-children
```
+As noted above, the `condition` here is evaluated on each child.
+To have it evaluated on the parent context instead, you can write:
+
+```
+- condition:
+ sensor: service.isUp
+ equals: true
+ steps:
+ - type: workflow
+ target: children
+ concurrency: max(1, min(33%, 5))
+ steps:
+ - invoke-effector effector-on-children
+```
### Defining Custom Workflow Steps
diff --git a/guide/blueprints/workflow/settings.md b/guide/blueprints/workflow/settings.md
index ab7af87..c9d409c 100644
--- a/guide/blueprints/workflow/settings.md
+++ b/guide/blueprints/workflow/settings.md
@@ -359,7 +359,9 @@
Where not explicitly set, a system-wide retention default is used. This can be configured in `brooklyn.properties` using
the key `workflow.retention.default`. If no supplied, Brooklyn defaults to `3`, meaning it will keep the three most
-recent invocations of a workflow, with no time limit, and
+recent invocations of a workflow, with no time limit.
+
+Workflows may be kept in-memory for a longer period than persisted to disk, depending on the memory available. This allows, for example, `disabled` and `0` to be indicated to minimize persistence requirements, while maintaining UI and API access to workflow state "softly", that is to say if memory permits. The key `workflow.retention.default.soft` can be configured in `brooklyn.properties` to override the default limit of such workflows kept in memory, from the default value of `3`, or the expression `soft <soft_retention_value>` can be used as part of a retention expression, typically at the end, to customize it per-workflow. If the soft limit is less than or the same as the standard limit there is no apparent effect, as workflow state can be retrieved from in-memory or on-disk. Active workflows are always kept in memory.
Workflow retention is done on a per-entity basis based by default on a hash of the workflow name. Typically workflow
definitions for effectors, sensors, and policies all get unique names for that definition, so the retention applies
@@ -398,6 +400,8 @@
* `max` means completed workflow instances must be retained if they meet any of the constraints implied by
the `<value>` arguments, i.e. `max(2, 3, 1h, 2h)` means to keep the 3 most recent instances irrespective of when
they run, and to keep all instances for up to two hours
+* `<value> soft <soft_value>` where `<soft_value>` can be any of the above, to specify an explicit in-memory soft-retention limit, and `<value>` is any retention expression indicating the normal on-disk retention (where `<value>` must not indicate an additional `soft` or `hard` expression)
+* `<value> hard` as per `soft` but indicating that the `<value>` is both the on-disk and in-memory limit
* `disabled`, to prevent persistence of a workflow, causing less work for the system where workflows don't need to be
stored; such workflows will not be replayable by an operator or recoverable on failover;
this should not be used with workflows that acquire a `lock` unless the entity has special handlers to clear locks
diff --git a/guide/blueprints/workflow/steps/steps.yaml b/guide/blueprints/workflow/steps/steps.yaml
index 50bed27..f55141b 100644
--- a/guide/blueprints/workflow/steps/steps.yaml
+++ b/guide/blueprints/workflow/steps/steps.yaml
@@ -104,6 +104,16 @@
* `value`: the value to return
output: the value indicated
+ - name: if
+ summary: |
+ Provides shorthand for a simple condition and step.
+ shorthand: '`${condition_target} [ "==" ${condition_equals} ] [ " then " ${step...} ]`'
+ input: |
+ * `condition_target`: a condition to evaluate or an expression to check (for truthiness, unless a condition_equals is supplied)
+ * `condition_equals`: a value to compare for equality against the supplied condition_target (which should not be a condition if this is used)
+ * `step` or `steps`: a subworkflow to run if the condition passes
+ output: the result of the supplied step or steps
+
- name: wait
summary: |
Waits for a value which might not yet be resolved, or a task which might not have finished,
@@ -169,7 +179,7 @@
`JITTER` as either a percentage or real factor by which to jitter the result with randomness, 0 being none, 100% being up to double, and -100% being down to zero;
and `MAX` to specify a maximum duration; for example,
`backoff 1s 1s 10s` will retry after 1 second the first two times, then after 10 seconds on subsequent instances;
- and `backoff 1s 2s backoff 3x max 1m` will retry after 1 second then 2s then 6s then 18s then 54s then 60s each subsequent time
+ and `backoff 1s 2s increasing 3x up to 1m` will retry after 1 second then 2s then 6s then 18s then 54s then 60s each subsequent time
* `hash`: an optional hash expression to identify related retries in a workflow instance; all retry blocks with the same `hash` will share counts
for the purpose of counting limits (although the limits themselves are as per the definition in each retry block),
which can be useful if there are different steps which might fail in different ways but the overall retry behaviour should be preserved
@@ -220,11 +230,26 @@
output: if `reducing` is specified, the final value of those variables,
otherwise the output from the last step in the nested workflow or a list of such outputs if supplied a `target` list
- - name: foreach
- summary: Runs nested workflow over a list using the specified variable name, equivalent to `workflow` when looping over a list
- shorthand: '`foreach TARGET_VAR_NAME [ in TARGET ]`'
+ - name: subworkflow
+ summary: |
+ A simple set of steps to run, like `workflow` but more restricted in options,
+ and sharing workflow variables with the containing workflow.
+ No `target` or `concurrency` can be specified, and all containing workflow variables are in scope,
+
+ A `name` can be given to a block of commands to improve understandability,
+ A `condition` can be set on the entire block
+ , but not allowing a target Runs nested workflow, optionally over an indicated target.
+ This step type is described in more detail [here](../nested-workflow.html).
+ shorthand: none; this step type is implied if there is no `step` shorthand or type indicated when there are `steps` defined
input: |
- * `steps`: a list of steps to run, run in a separate context
+
+ - name: foreach
+ summary: |
+ Runs nested workflow over a list using the specified variable name, equivalent to `workflow` when looping over a list,
+ with support for including a single step as shorthand
+ shorthand: '`foreach TARGET_VAR_NAME [ in TARGET [ do STEP ]]`'
+ input: |
+ * `step` or `steps`: a list of steps to run, run in a separate context
* `target_var_name`: the name of the variable that should be set in nested workflows to refer to the element in the target list,
with the additional behavior that if this is of the "spread map syntax" form `{KEY,KEY2}`, each element in the target list will be assumed to be a map
and the keys "KEY" and "KEY2" will be extracted and each one set as a variable in the nested workflow
@@ -379,11 +404,14 @@
steps:
- name: invoke-effector
summary: Invokes an effector
- shorthand: '`invoke-effector EFFECTOR`'
+ shorthand: '`invoke-effector EFFECTOR [ "on" ENTITY ] [ "with" ARGS ]`'
input: |
* `effector`: the name of the effector to invoke
- * `entity`: optional entity or entity ID where the effector should be invoked
- * `args`: map of argument names to values to pass to the effector
+ * `entity`: optional entity or entity ID where the effector should be invoked,
+ if not the entity where the workflow is running
+ * `args`: map of argument names to values to pass to the effector;
+ if supplied as shorthand, it expects the form `arg1=v1, arg2=v2`;
+ complex arguments are recommended to be passed using longhand syntax
output: the returned object from the invoked effector
- name: set-config
@@ -407,8 +435,11 @@
the value will be coerced to the given type, e.g. to force conversion to an integer or to a bean registered type;
if the `name` contains bracketed portions, these are treated as keys in a map or positions in list to be set
* `value`: the value to set
- * `require`: a condition to evaluate against the sensor value while holding the lock on the sensor,
- used to enable atomic operations similar to the `lock` workflow setting
+ * `require`: a condition to evaluate against the sensor value,
+ evaluated along with `value` while holding the lock on the sensor;
+ if the condition is not satisfied, an error is thrown and the sensor is not set,
+ enabling lightweight atomic check-and-set operations against the current value
+ without needing to use a explicit `lock` in the workflow
output: the output from the previous step, or null if this is the first step
- name: clear-config
@@ -536,6 +567,8 @@
the default behavior is to invoke an `on_update` effector at the child (if there is such an effector, otherwise do nothing);
if the name or any policies may need to change on update, that should be considered in this workflow;
if the `update-children` is performed frequently, it might be efficient in this method to check whether the `item` has changed
+ * `on_update_child`: as `on_update`, but run in the context of the `child` entity for easier configuration there,
+ still with access to `item` and `index`
* `on_delete`: a workflow to run on each child which no longer has a corresponding item prior to its being deleted;
the default behavior is to invoke an `on_delete` effector at the child (if there is such an effector, or nothing);
diff --git a/guide/dev/tips/debugging-remote-brooklyn.md b/guide/dev/tips/debugging-remote-brooklyn.md
index 84c305e..f688c18 100644
--- a/guide/dev/tips/debugging-remote-brooklyn.md
+++ b/guide/dev/tips/debugging-remote-brooklyn.md
@@ -25,7 +25,7 @@
{% highlight json %}
{
- "version": "1.1.0-SNAPSHOT", {% comment %}BROOKLYN_VERSION{% endcomment %}
+ "version": "1.2.0-SNAPSHOT", {% comment %}BROOKLYN_VERSION{% endcomment %}
"buildSha1": "c0fdc15291702281acdebf1b11d431a6385f5224",
"buildBranch": "UNKNOWN"
}
diff --git a/guide/misc/release-notes.md b/guide/misc/release-notes.md
index bf8eeb0..08d02db 100644
--- a/guide/misc/release-notes.md
+++ b/guide/misc/release-notes.md
@@ -14,36 +14,10 @@
### New Features
-
### Backwards Compatibility
-Changes since 0.12.0:
+Changes since 1.1.0:
-1. BOM files that do not declare a version now give the version of the bundle to their entities,
- rather than the default `0.0.0-SNAPSHOT` version.
- When loading types, the version can now be specified as any Brooklyn-valid version string
- equivalent to the OSGi version (e.g. `1-SNAPSHOT` or `1.0.0.SNAPSHOT`).
-
-1. Some catalog methods may return the same type multiple times, if contained in multiple bundles.
- Previously only one of the bundle's definition of the type was returned.
- Except for anonymous bundles it is no longer allowed to have give items with the same name and version.
- (This is required to prevent Brooklyn from getting in to a state where it cannot rebind.)
-
-1. Value resolution is now supported for config default values. Previously these would be coerced but
- not resolved beyond that -- i.e. TaskFactory values would not have tasks evaluated, and Map and
- Collection values would not be deeply resolved with their internals coerced or evaluated.
- This makes the semantics of default values consistent with explicit config values.
-
-1. Deep config resolution of nested items has changed to be consistent with when deep config applies.
- Deep config applies to maps and collections, but previously any Iterable contained therein
- would have a recursive deep config evaluation. Now this is limited to nested Collection types
- (Lists, Sets, etc) and Maps; nested Iterable instances that are not also Collections are
- no longer traversed and resolved recursively. This makes their nested resolution consistent
- with when such instances are non-nested config value, as deep resolution was not applied there.
- This mainly affects PortRange, where previously if set directly on a config key it would return
- the PortRange value but if accessed in a map such as `shell.env` any non-default value would
- be expanded as a list `[1, 2]` (but default values would not be expanded, as per previous point,
- but now they are).
For changes in prior versions, please refer to the release notes for
-[0.12.0]({{ site.path.v | relative_url }}/0.12.0/misc/release-notes.html).
+[1.1.0]({{ site.path.v | relative_url }}/1.1.0/misc/release-notes.html).
diff --git a/guide/ops/rest.md b/guide/ops/rest.md
index c0bc503..cf96c10 100644
--- a/guide/ops/rest.md
+++ b/guide/ops/rest.md
@@ -11,12 +11,12 @@
item `cluster` in the web console is displayed at:
<!-- BROOKLYN_VERSION_BELOW -->
- http://localhost:8081/#v1/catalog/entities/cluster:1.1.0-SNAPSHOT
+ http://localhost:8081/#v1/catalog/entities/cluster:1.2.0-SNAPSHOT
And in the REST API it is accessed at:
<!-- BROOKLYN_VERSION_BELOW -->
- http://localhost:8081/v1/catalog/entities/cluster:1.1.0-SNAPSHOT
+ http://localhost:8081/v1/catalog/entities/cluster:1.2.0-SNAPSHOT
A full reference for the REST API is automatically generated by the server at runtime.
It can be found in the Brooklyn web console, under the Script tab.
diff --git a/index.md b/index.md
index c2fe705..8b6589b 100644
--- a/index.md
+++ b/index.md
@@ -8,7 +8,7 @@
Consider looking at:
* [the brooklyn website](/website/)
-* [the brooklyn user guide (version 1.1.0-SNAPSHOT)](guide/) <span> <!-- BROOKLYN_VERSION --> </span>
+* [the brooklyn user guide (version 1.2.0-SNAPSHOT)](guide/) <span> <!-- BROOKLYN_VERSION --> </span>
Also see the file <code>README.md</code> in this directory.
diff --git a/website/developers/code/index.md b/website/developers/code/index.md
index 35fde78..ee8499a 100644
--- a/website/developers/code/index.md
+++ b/website/developers/code/index.md
@@ -21,7 +21,7 @@
mvn clean install
{% endhighlight %}
-This will produce an artifact in `brooklyn-dist/dist/brooklyn-dist-1.1.0-SNAPSHOT-dist.tar.gz` <!-- BROOKLYN_VERSION -->
+This will produce an artifact in `brooklyn-dist/dist/brooklyn-dist-1.2.0-SNAPSHOT-dist.tar.gz` <!-- BROOKLYN_VERSION -->
which you can use [in the usual way](/guide/start/running.html).
Some options which may be useful:
diff --git a/website/developers/committers/release-process/environment-variables.md b/website/developers/committers/release-process/environment-variables.md
index 1916fb4..93758b6 100644
--- a/website/developers/committers/release-process/environment-variables.md
+++ b/website/developers/committers/release-process/environment-variables.md
@@ -9,7 +9,7 @@
{% highlight bash %}
# The version currently set on the master branch (BROOKLYN_VERSION_BELOW)
-OLD_MASTER_VERSION=1.1.0-SNAPSHOT
+OLD_MASTER_VERSION=1.2.0-SNAPSHOT
# The next version to be set on the master branch
NEW_MASTER_VERSION=9.9.9-SNAPSHOT
diff --git a/website/meta/versions.md b/website/meta/versions.md
index 6b61982..5f4c618 100644
--- a/website/meta/versions.md
+++ b/website/meta/versions.md
@@ -19,6 +19,10 @@
Apache Brooklyn has made the following releases:
+* **[1.1.0](/v/1.1.0)**: Workflows and Container commands
+
+* **[1.0.0](/v/1.0.0/)**: Major Release
+
* **[0.12.0](/v/0.12.0/)**: OSGI container runtime, improved catalog and bundle integration (September 2017)
* **[0.11.0](/v/0.11.0/)**: Improved cloud support, additional blueprinting features (May 2017)
