Update docs
diff --git a/docs/dyn/firebaserules_v1.projects.releases.html b/docs/dyn/firebaserules_v1.projects.releases.html
new file mode 100644
index 0000000..8d9f299
--- /dev/null
+++ b/docs/dyn/firebaserules_v1.projects.releases.html
@@ -0,0 +1,503 @@
+<html><body>
+<style>
+
+body, h1, h2, h3, div, span, p, pre, a {
+ margin: 0;
+ padding: 0;
+ border: 0;
+ font-weight: inherit;
+ font-style: inherit;
+ font-size: 100%;
+ font-family: inherit;
+ vertical-align: baseline;
+}
+
+body {
+ font-size: 13px;
+ padding: 1em;
+}
+
+h1 {
+ font-size: 26px;
+ margin-bottom: 1em;
+}
+
+h2 {
+ font-size: 24px;
+ margin-bottom: 1em;
+}
+
+h3 {
+ font-size: 20px;
+ margin-bottom: 1em;
+ margin-top: 1em;
+}
+
+pre, code {
+ line-height: 1.5;
+ font-family: Monaco, 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Lucida Console', monospace;
+}
+
+pre {
+ margin-top: 0.5em;
+}
+
+h1, h2, h3, p {
+ font-family: Arial, sans serif;
+}
+
+h1, h2, h3 {
+ border-bottom: solid #CCC 1px;
+}
+
+.toc_element {
+ margin-top: 0.5em;
+}
+
+.firstline {
+ margin-left: 2 em;
+}
+
+.method {
+ margin-top: 1em;
+ border: solid 1px #CCC;
+ padding: 1em;
+ background: #EEE;
+}
+
+.details {
+ font-weight: bold;
+ font-size: 14px;
+}
+
+</style>
+
+<h1><a href="firebaserules_v1.html">Firebase Rules API</a> . <a href="firebaserules_v1.projects.html">projects</a> . <a href="firebaserules_v1.projects.releases.html">releases</a></h1>
+<h2>Instance Methods</h2>
+<p class="toc_element">
+ <code><a href="#create">create(name=None, body, x__xgafv=None)</a></code></p>
+<p class="firstline">Create a `Release`.</p>
+<p class="toc_element">
+ <code><a href="#delete">delete(name=None, x__xgafv=None)</a></code></p>
+<p class="firstline">Delete a `Release` by resource name.</p>
+<p class="toc_element">
+ <code><a href="#get">get(name=None, x__xgafv=None)</a></code></p>
+<p class="firstline">Get a `Release` by name.</p>
+<p class="toc_element">
+ <code><a href="#list">list(name=None, pageSize=None, filter=None, pageToken=None, x__xgafv=None)</a></code></p>
+<p class="firstline">List the `Release` values for a project. This list may optionally be</p>
+<p class="toc_element">
+ <code><a href="#list_next">list_next(previous_request, previous_response)</a></code></p>
+<p class="firstline">Retrieves the next page of results.</p>
+<p class="toc_element">
+ <code><a href="#update">update(name=None, body, x__xgafv=None)</a></code></p>
+<p class="firstline">Update a `Release`.</p>
+<h3>Method Details</h3>
+<div class="method">
+ <code class="details" id="create">create(name=None, body, x__xgafv=None)</code>
+ <pre>Create a `Release`.
+
+Release names should reflect the developer's deployment practices. For
+example, the release name may include the environment name, application
+name, application version, or any other name meaningful to the developer.
+Once a `Release` refers to a `Ruleset`, the rules can be enforced by
+Firebase Rules-enabled services.
+
+More than one `Release` may be 'live' concurrently. Consider the following
+three `Release` names for `projects/foo` and the `Ruleset` to which they
+refer.
+
+Release Name | Ruleset Name
+--------------------------------|-------------
+projects/foo/releases/prod | projects/foo/rulesets/uuid123
+projects/foo/releases/prod/beta | projects/foo/rulesets/uuid123
+projects/foo/releases/prod/v23 | projects/foo/rulesets/uuid456
+
+The table reflects the `Ruleset` rollout in progress. The `prod` and
+`prod/beta` releases refer to the same `Ruleset`. However, `prod/v23`
+refers to a new `Ruleset`. The `Ruleset` reference for a `Release` may be
+updated using the UpdateRelease method, and the custom `Release` name
+may be referenced by specifying the `X-Firebase-Rules-Release-Name` header.
+
+Args:
+ name: string, Resource name for the project which owns this `Release`.
+
+Format: `projects/{project_id}` (required)
+ body: object, The request body. (required)
+ The object takes the form of:
+
+{ # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
+ # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
+ "updateTime": "A String", # Time the release was updated.
+ # @OutputOnly
+ "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
+ # exist the `Release` to be created.
+ "createTime": "A String", # Time the release was created.
+ # @OutputOnly
+ "name": "A String", # Resource name for the `Release`.
+ #
+ # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
+ # which affords developers a great deal of flexibility in mapping the name
+ # to the style that best fits their existing development practices. For
+ # example, a name could refer to an environment, an app, a version, or some
+ # combination of three.
+ #
+ # In the table below, for the project name `projects/foo`, the following
+ # relative release paths show how flat and structured names might be chosen
+ # to match a desired development / deployment strategy.
+ #
+ # Use Case | Flat Name | Structured Name
+ # -------------|---------------------|----------------
+ # Environments | releases/qa | releases/qa
+ # Apps | releases/app1_qa | releases/app1/qa
+ # Versions | releases/app1_v2_qa | releases/app1/v2/qa
+ #
+ # The delimiter between the release name path elements can be almost anything
+ # and it should work equally well with the release name list filter, but in
+ # many ways the structured paths provide a clearer picture of the
+ # relationship between `Release` instances.
+ #
+ # Format: `projects/{project_id}/releases/{release_id}`
+ }
+
+ x__xgafv: string, V1 error format.
+ Allowed values
+ 1 - v1 error format
+ 2 - v2 error format
+
+Returns:
+ An object of the form:
+
+ { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
+ # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
+ "updateTime": "A String", # Time the release was updated.
+ # @OutputOnly
+ "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
+ # exist the `Release` to be created.
+ "createTime": "A String", # Time the release was created.
+ # @OutputOnly
+ "name": "A String", # Resource name for the `Release`.
+ #
+ # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
+ # which affords developers a great deal of flexibility in mapping the name
+ # to the style that best fits their existing development practices. For
+ # example, a name could refer to an environment, an app, a version, or some
+ # combination of three.
+ #
+ # In the table below, for the project name `projects/foo`, the following
+ # relative release paths show how flat and structured names might be chosen
+ # to match a desired development / deployment strategy.
+ #
+ # Use Case | Flat Name | Structured Name
+ # -------------|---------------------|----------------
+ # Environments | releases/qa | releases/qa
+ # Apps | releases/app1_qa | releases/app1/qa
+ # Versions | releases/app1_v2_qa | releases/app1/v2/qa
+ #
+ # The delimiter between the release name path elements can be almost anything
+ # and it should work equally well with the release name list filter, but in
+ # many ways the structured paths provide a clearer picture of the
+ # relationship between `Release` instances.
+ #
+ # Format: `projects/{project_id}/releases/{release_id}`
+ }</pre>
+</div>
+
+<div class="method">
+ <code class="details" id="delete">delete(name=None, x__xgafv=None)</code>
+ <pre>Delete a `Release` by resource name.
+
+Args:
+ name: string, Resource name for the `Release` to delete.
+
+Format: `projects/{project_id}/releases/{release_id}` (required)
+ x__xgafv: string, V1 error format.
+ Allowed values
+ 1 - v1 error format
+ 2 - v2 error format
+
+Returns:
+ An object of the form:
+
+ { # A generic empty message that you can re-use to avoid defining duplicated
+ # empty messages in your APIs. A typical example is to use it as the request
+ # or the response type of an API method. For instance:
+ #
+ # service Foo {
+ # rpc Bar(google.protobuf.Empty) returns (google.protobuf.Empty);
+ # }
+ #
+ # The JSON representation for `Empty` is empty JSON object `{}`.
+ }</pre>
+</div>
+
+<div class="method">
+ <code class="details" id="get">get(name=None, x__xgafv=None)</code>
+ <pre>Get a `Release` by name.
+
+
+Args:
+ name: string, Resource name of the `Release`.
+
+
+Format: `projects/{project_id}/releases/{release_id}` (required)
+ x__xgafv: string, V1 error format.
+ Allowed values
+ 1 - v1 error format
+ 2 - v2 error format
+
+Returns:
+ An object of the form:
+
+ { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
+ # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
+ "updateTime": "A String", # Time the release was updated.
+ # @OutputOnly
+ "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
+ # exist the `Release` to be created.
+ "createTime": "A String", # Time the release was created.
+ # @OutputOnly
+ "name": "A String", # Resource name for the `Release`.
+ #
+ # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
+ # which affords developers a great deal of flexibility in mapping the name
+ # to the style that best fits their existing development practices. For
+ # example, a name could refer to an environment, an app, a version, or some
+ # combination of three.
+ #
+ # In the table below, for the project name `projects/foo`, the following
+ # relative release paths show how flat and structured names might be chosen
+ # to match a desired development / deployment strategy.
+ #
+ # Use Case | Flat Name | Structured Name
+ # -------------|---------------------|----------------
+ # Environments | releases/qa | releases/qa
+ # Apps | releases/app1_qa | releases/app1/qa
+ # Versions | releases/app1_v2_qa | releases/app1/v2/qa
+ #
+ # The delimiter between the release name path elements can be almost anything
+ # and it should work equally well with the release name list filter, but in
+ # many ways the structured paths provide a clearer picture of the
+ # relationship between `Release` instances.
+ #
+ # Format: `projects/{project_id}/releases/{release_id}`
+ }</pre>
+</div>
+
+<div class="method">
+ <code class="details" id="list">list(name=None, pageSize=None, filter=None, pageToken=None, x__xgafv=None)</code>
+ <pre>List the `Release` values for a project. This list may optionally be
+filtered by `Release` name or `Ruleset` id or both.
+
+Args:
+ name: string, Resource name for the project.
+
+Format: `projects/{project_id}` (required)
+ pageSize: integer, Page size to load. Maximum of 100. Defaults to 10.
+Note: `page_size` is just a hint and the service may choose to load less
+than `page_size` due to the size of the output. To traverse all of the
+releases, caller should iterate until the `page_token` is empty.
+ filter: string, `Release` filter. The list method supports filters with restrictions on the
+`Release` `name` and also on the `Ruleset` `ruleset_name`.
+
+Example 1) A filter of 'name=prod*' might return `Release`s with names
+within 'projects/foo' prefixed with 'prod':
+
+Name | Ruleset Name
+------------------------------|-------------
+projects/foo/releases/prod | projects/foo/rulesets/uuid1234
+projects/foo/releases/prod/v1 | projects/foo/rulesets/uuid1234
+projects/foo/releases/prod/v2 | projects/foo/rulesets/uuid8888
+
+Example 2) A filter of `name=prod* ruleset_name=uuid1234` would return only
+`Release` instances for 'projects/foo' with names prefixed with 'prod'
+referring to the same `Ruleset` name of 'uuid1234':
+
+Name | Ruleset Name
+------------------------------|-------------
+projects/foo/releases/prod | projects/foo/rulesets/1234
+projects/foo/releases/prod/v1 | projects/foo/rulesets/1234
+
+In the examples, the filter parameters refer to the search filters for
+release and ruleset names are relative to the project releases and rulesets
+collections. Fully qualified prefixed may also be used. e.g.
+`name=projects/foo/releases/prod* ruleset_name=projects/foo/rulesets/uuid1`
+ pageToken: string, Next page token for the next batch of `Release` instances.
+ x__xgafv: string, V1 error format.
+ Allowed values
+ 1 - v1 error format
+ 2 - v2 error format
+
+Returns:
+ An object of the form:
+
+ { # The response for FirebaseRulesService.ListReleases.
+ "nextPageToken": "A String", # The pagination token to retrieve the next page of results. If the value is
+ # empty, no further results remain.
+ "releases": [ # List of `Release` instances.
+ { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
+ # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
+ "updateTime": "A String", # Time the release was updated.
+ # @OutputOnly
+ "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
+ # exist the `Release` to be created.
+ "createTime": "A String", # Time the release was created.
+ # @OutputOnly
+ "name": "A String", # Resource name for the `Release`.
+ #
+ # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
+ # which affords developers a great deal of flexibility in mapping the name
+ # to the style that best fits their existing development practices. For
+ # example, a name could refer to an environment, an app, a version, or some
+ # combination of three.
+ #
+ # In the table below, for the project name `projects/foo`, the following
+ # relative release paths show how flat and structured names might be chosen
+ # to match a desired development / deployment strategy.
+ #
+ # Use Case | Flat Name | Structured Name
+ # -------------|---------------------|----------------
+ # Environments | releases/qa | releases/qa
+ # Apps | releases/app1_qa | releases/app1/qa
+ # Versions | releases/app1_v2_qa | releases/app1/v2/qa
+ #
+ # The delimiter between the release name path elements can be almost anything
+ # and it should work equally well with the release name list filter, but in
+ # many ways the structured paths provide a clearer picture of the
+ # relationship between `Release` instances.
+ #
+ # Format: `projects/{project_id}/releases/{release_id}`
+ },
+ ],
+ }</pre>
+</div>
+
+<div class="method">
+ <code class="details" id="list_next">list_next(previous_request, previous_response)</code>
+ <pre>Retrieves the next page of results.
+
+Args:
+ previous_request: The request for the previous page. (required)
+ previous_response: The response from the request for the previous page. (required)
+
+Returns:
+ A request object that you can call 'execute()' on to request the next
+ page. Returns None if there are no more items in the collection.
+ </pre>
+</div>
+
+<div class="method">
+ <code class="details" id="update">update(name=None, body, x__xgafv=None)</code>
+ <pre>Update a `Release`.
+
+Only updates to the `ruleset_name` field will be honored. `Release` rename
+is not supported. To create a `Release` use the CreateRelease method
+instead.
+
+Args:
+ name: string, Resource name for the `Release`.
+
+`Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
+which affords developers a great deal of flexibility in mapping the name
+to the style that best fits their existing development practices. For
+example, a name could refer to an environment, an app, a version, or some
+combination of three.
+
+In the table below, for the project name `projects/foo`, the following
+relative release paths show how flat and structured names might be chosen
+to match a desired development / deployment strategy.
+
+Use Case | Flat Name | Structured Name
+-------------|---------------------|----------------
+Environments | releases/qa | releases/qa
+Apps | releases/app1_qa | releases/app1/qa
+Versions | releases/app1_v2_qa | releases/app1/v2/qa
+
+The delimiter between the release name path elements can be almost anything
+and it should work equally well with the release name list filter, but in
+many ways the structured paths provide a clearer picture of the
+relationship between `Release` instances.
+
+Format: `projects/{project_id}/releases/{release_id}`
+ (required)
+ body: object, The request body. (required)
+ The object takes the form of:
+
+{ # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
+ # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
+ "updateTime": "A String", # Time the release was updated.
+ # @OutputOnly
+ "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
+ # exist the `Release` to be created.
+ "createTime": "A String", # Time the release was created.
+ # @OutputOnly
+ "name": "A String", # Resource name for the `Release`.
+ #
+ # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
+ # which affords developers a great deal of flexibility in mapping the name
+ # to the style that best fits their existing development practices. For
+ # example, a name could refer to an environment, an app, a version, or some
+ # combination of three.
+ #
+ # In the table below, for the project name `projects/foo`, the following
+ # relative release paths show how flat and structured names might be chosen
+ # to match a desired development / deployment strategy.
+ #
+ # Use Case | Flat Name | Structured Name
+ # -------------|---------------------|----------------
+ # Environments | releases/qa | releases/qa
+ # Apps | releases/app1_qa | releases/app1/qa
+ # Versions | releases/app1_v2_qa | releases/app1/v2/qa
+ #
+ # The delimiter between the release name path elements can be almost anything
+ # and it should work equally well with the release name list filter, but in
+ # many ways the structured paths provide a clearer picture of the
+ # relationship between `Release` instances.
+ #
+ # Format: `projects/{project_id}/releases/{release_id}`
+ }
+
+ x__xgafv: string, V1 error format.
+ Allowed values
+ 1 - v1 error format
+ 2 - v2 error format
+
+Returns:
+ An object of the form:
+
+ { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
+ # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
+ "updateTime": "A String", # Time the release was updated.
+ # @OutputOnly
+ "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
+ # exist the `Release` to be created.
+ "createTime": "A String", # Time the release was created.
+ # @OutputOnly
+ "name": "A String", # Resource name for the `Release`.
+ #
+ # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
+ # which affords developers a great deal of flexibility in mapping the name
+ # to the style that best fits their existing development practices. For
+ # example, a name could refer to an environment, an app, a version, or some
+ # combination of three.
+ #
+ # In the table below, for the project name `projects/foo`, the following
+ # relative release paths show how flat and structured names might be chosen
+ # to match a desired development / deployment strategy.
+ #
+ # Use Case | Flat Name | Structured Name
+ # -------------|---------------------|----------------
+ # Environments | releases/qa | releases/qa
+ # Apps | releases/app1_qa | releases/app1/qa
+ # Versions | releases/app1_v2_qa | releases/app1/v2/qa
+ #
+ # The delimiter between the release name path elements can be almost anything
+ # and it should work equally well with the release name list filter, but in
+ # many ways the structured paths provide a clearer picture of the
+ # relationship between `Release` instances.
+ #
+ # Format: `projects/{project_id}/releases/{release_id}`
+ }</pre>
+</div>
+
+</body></html>
\ No newline at end of file