Update Releases documentation

app/views/projects/releases/index.html.haml

@@ -2,4 +2,4 @@
 - page_title _('Releases')
 
 %div{ class: container_class }
-  #js-releases-page{ data: { project_id: @project.id, illustration_path: image_path('illustrations/releases.svg'), documentation_path: help_page_path('user/project/releases') } }
+  #js-releases-page{ data: { project_id: @project.id, illustration_path: image_path('illustrations/releases.svg'), documentation_path: help_page_path('user/project/releases/index') } }

doc/api/releases.md

 # Releases API
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/41766) in GitLab 11.7.
-> - Using this API you can manipulate GitLab's [Release](../user/project/releases.md) entries.
+> - Using this API you can manipulate GitLab's [Release](../user/project/releases/index.md) entries.
 
 ## List Releases
 

doc/user/project/index.md

@@ -72,12 +72,15 @@ website with GitLab Pages
 
 **Other features:**
 
-- [Wiki](wiki/index.md): Document your GitLab project in an integrated Wiki
-- [Snippets](../snippets.md): Store, share and collaborate on code snippets
-- [Cycle Analytics](cycle_analytics.md): Review your development lifecycle
-- [Syntax highlighting](highlighting.md): An alternative to customize
-your code blocks, overriding GitLab's default choice of language
-- [Badges](badges.md): Badges for the project overview
+- [Wiki](wiki/index.md): document your GitLab project in an integrated Wiki.
+- [Snippets](../snippets.md): store, share and collaborate on code snippets.
+- [Cycle Analytics](cycle_analytics.md): review your development lifecycle.
+- [Syntax highlighting](highlighting.md): an alternative to customize
+your code blocks, overriding GitLab's default choice of language.
+- [Badges](badges.md): badges for the project overview.
+- [Releases](releases/index.md): a way to track deliverables in your project as snapshot in time of
+the source, build output, and other metadata or artifacts
+associated with a released version of your code.
 
 ### Project's integrations
 

doc/user/project/releases.md

-# Releases
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/41766) in GitLab 11.7.
-
-It's typical to create a [Git tag](../../university/training/topics/tags.md) at
-the moment of release to introduce a checkpoint in your source code
-history, but in most cases your users will need compiled objects or other
-assets output by your CI system to use them, not just the raw source
-code.
-
-GitLab's **Releases** are a way to track deliverables in your project. Consider them
-a snapshot in time of the source, build output, and other metadata or artifacts
-associated with a released version of your code.
-
-At the moment, you can create Release entries via the [Releases API](../../api/releases.md);
-we recommend doing this as one of the last steps in your CI/CD release pipeline.
-
-## Getting started with Releases
-
-Start by giving a [description](#release-description) to the Release and
-including its [assets](#release-assets), as follows.
-
-### Release description
-
-Every Release has a description. You can add any text you like, but we recommend
-including a changelog to describe the content of your release. This will allow
-your users to quickly scan the differences between each one you publish.
-
-NOTE: **Note:**
-[Git's tagging messages](https://git-scm.com/book/en/v2/Git-Basics-Tagging) and
-Release descriptions are unrelated. Description supports [markdown](../markdown.md).
-
-### Release assets
-
-You can currently add the following types of assets to each Release:
-
-- [Source code](#source-code): state of the repo at the time of the Release
-- [Links](#links): to content such as built binaries or documentation
-
-GitLab will support more asset types in the future, including objects such
-as pre-built packages, compliance/security evidence, or container images.
-
-#### Source code
-
-GitLab automatically generate `zip`, `tar.gz`, `tar.bz2` and `tar`
-archived source code from the given Git tag. These are read-only assets.
-
-#### Links
-
-A link is any URL which can point to whatever you like; documentation, built
-binaries, or other related materials. These can be both internal or external
-links from your GitLab instance.
-
-## Releases list
-
-Navigate to **Project > Releases** in order to see the list of releases for a given
-project.
-
-![Releases list](img/releases.png)
+This document was moved to [another location](releases/index.md).

doc/user/project/releases/index.md

+# Releases
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/41766) in GitLab 11.7.
+
+It's typical to create a [Git tag](../../../university/training/topics/tags.md) at
+the moment of release to introduce a checkpoint in your source code
+history, but in most cases your users will need compiled objects or other
+assets output by your CI system to use them, not just the raw source
+code.
+
+GitLab's **Releases** are a way to track deliverables in your project. Consider them
+a snapshot in time of the source, build output, and other metadata or artifacts
+associated with a released version of your code.
+
+At the moment, you can create Release entries via the [Releases API](../../../api/releases.md);
+we recommend doing this as one of the last steps in your CI/CD release pipeline.
+
+## Getting started with Releases
+
+Start by giving a [description](#release-description) to the Release and
+including its [assets](#release-assets), as follows.
+
+### Release description
+
+Every Release has a description. You can add any text you like, but we recommend
+including a changelog to describe the content of your release. This will allow
+your users to quickly scan the differences between each one you publish.
+
+NOTE: **Note:**
+[Git's tagging messages](https://git-scm.com/book/en/v2/Git-Basics-Tagging) and
+Release descriptions are unrelated. Description supports [markdown](../../markdown.md).
+
+### Release assets
+
+You can currently add the following types of assets to each Release:
+
+- [Source code](#source-code): state of the repo at the time of the Release
+- [Links](#links): to content such as built binaries or documentation
+
+GitLab will support more asset types in the future, including objects such
+as pre-built packages, compliance/security evidence, or container images.
+
+#### Source code
+
+GitLab automatically generate `zip`, `tar.gz`, `tar.bz2` and `tar`
+archived source code from the given Git tag. These are read-only assets.
+
+#### Links
+
+A link is any URL which can point to whatever you like; documentation, built
+binaries, or other related materials. These can be both internal or external
+links from your GitLab instance.
+
+## Releases list
+
+Navigate to **Project > Releases** in order to see the list of releases for a given
+project.
+
+![Releases list](img/releases.png)

doc/workflow/releases.md

 # Releases
 
-NOTE: In GitLab 11.7, we introduced the full fledged [releases](../user/project/releases.md) feature. You can still create release notes on this page, but the new method is preferred.
+NOTE: In GitLab 11.7, we introduced the full fledged [Releases](../user/project/releases/index.md)
+feature. You can still create release notes on this page, but the new method is preferred.
 
-You can add release notes to any git tag using the notes feature. Release notes 
-behave like any other markdown form in GitLab so you can write text and 
+You can add release notes to any git tag using the notes feature. Release notes
+behave like any other markdown form in GitLab so you can write text and
 drag-n-drop files to it. Release notes are stored in GitLab's database.
 
-There are several ways to add release notes: 
+There are several ways to add release notes:
 
-* In the interface, when you create a new git tag
-* In the interface, by adding a note to an existing git tag
-* Using the GitLab API
+- In the interface, when you create a new git tag
+- In the interface, by adding a note to an existing git tag
+- Using the GitLab API
 
 ## New tag page with release notes text area