Commit b3b50bb8 authored by Dmitriy Zaporozhets's avatar Dmitriy Zaporozhets

Merge branch 'master' of dev.gitlab.org:gitlab/gitlabhq

Signed-off-by: default avatarDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Conflicts:
	CHANGELOG
parents f9a11630 eabbb7be
v 7.3.0 v 7.3.0
- Always set the 'origin' remote in satellite actions - Always set the 'origin' remote in satellite actions
- Write authorized_keys in tmp/ during tests - Write authorized_keys in tmp/ during tests
- Expire Rack sessions after 1 week
v 7.2.0 v 7.2.0
- Explore page - Explore page
......
...@@ -6,5 +6,6 @@ Gitlab::Application.config.session_store( ...@@ -6,5 +6,6 @@ Gitlab::Application.config.session_store(
key: '_gitlab_session', key: '_gitlab_session',
secure: Gitlab.config.gitlab.https, secure: Gitlab.config.gitlab.https,
httponly: true, httponly: true,
expire_after: 1.week,
path: (Rails.application.config.relative_url_root.nil?) ? '/' : Rails.application.config.relative_url_root path: (Rails.application.config.relative_url_root.nil?) ? '/' : Rails.application.config.relative_url_root
) )
...@@ -153,6 +153,7 @@ git tag -a vx.x.0.rc1 -m 'Version x.x.0.rc1' ...@@ -153,6 +153,7 @@ git tag -a vx.x.0.rc1 -m 'Version x.x.0.rc1'
Merge the RC1 EE code into GitLab.com. Merge the RC1 EE code into GitLab.com.
Once the build is green, create a package. Once the build is green, create a package.
If there are big database migrations consider testing them with the production db on a VM.
Try to deploy in the morning. Try to deploy in the morning.
It is important to do this as soon as possible, so we can catch any errors before we release the full version. It is important to do this as soon as possible, so we can catch any errors before we release the full version.
...@@ -210,9 +211,16 @@ For GitLab EE, append `-ee` to the branches and tags. ...@@ -210,9 +211,16 @@ For GitLab EE, append `-ee` to the branches and tags.
`v.x.x.0-ee` `v.x.x.0-ee`
Merge CE into EE if needed. Note: Merge CE into EE if needed.
### **1. Create x-x-stable branch and push to the repositories** ### **1. Set VERSION to x.x.x and push**
- Change the GITLAB_SHELL_VERSION file in `master` of the CE repository if the version changed.
- Change the GITLAB_SHELL_VERSION file in `master` of the EE repository if the version changed.
- Change the VERSION file in `master` branch of the CE repository and commit and push.
- Change the VERSION file in `master` branch of the EE repository and commit and push.
### **2. Create x-x-stable branch and push to the repositories**
``` ```
git checkout master git checkout master
...@@ -221,22 +229,7 @@ git checkout -b x-x-stable ...@@ -221,22 +229,7 @@ git checkout -b x-x-stable
git push <remote> x-x-stable git push <remote> x-x-stable
``` ```
### **2. Build the Omnibus packages** ### **3. Create annotated tag vx.x.x**
Follow the [release doc in the Omnibus repository](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/release.md).
This can happen before tagging because Omnibus uses tags in its own repo and SHA1's to refer to the GitLab codebase.
### **3. Set VERSION to x.x.x and push**
Change the GITLAB_SHELL_VERSION file in `master` of the CE repository if the version changed.
Change the GITLAB_SHELL_VERSION file in `master` of the EE repository if the version changed.
Change the VERSION file in `master` branch of the CE repository and commit. Cherry-pick into the `x-x-stable` branch of CE.
Change the VERSION file in `master` branch of the EE repository and commit. Cherry-pick into the `x-x-stable-ee` branch of EE.
### **4. Create annotated tag vx.x.x**
In `x-x-stable` branch check for the SHA-1 of the commit with VERSION file changed. Tag that commit, In `x-x-stable` branch check for the SHA-1 of the commit with VERSION file changed. Tag that commit,
...@@ -246,12 +239,17 @@ git tag -a vx.x.0 -m 'Version x.x.0' xxxxx ...@@ -246,12 +239,17 @@ git tag -a vx.x.0 -m 'Version x.x.0' xxxxx
where `xxxxx` is SHA-1. where `xxxxx` is SHA-1.
### **5. Push the tag** ### **4. Push the tag**
``` ```
git push origin vx.x.0 git push origin vx.x.0
``` ```
### **5. Build the Omnibus packages**
Follow the [release doc in the Omnibus repository](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/release.md).
This can happen before tagging because Omnibus uses tags in its own repo and SHA1's to refer to the GitLab codebase.
### **6. Push to remotes** ### **6. Push to remotes**
For GitLab CE, push to dev, GitLab.com and GitHub. For GitLab CE, push to dev, GitLab.com and GitHub.
...@@ -260,8 +258,6 @@ For GitLab EE, push to the subscribers repo. ...@@ -260,8 +258,6 @@ For GitLab EE, push to the subscribers repo.
Make sure the branch is marked 'protected' on each of the remotes you pushed to. Make sure the branch is marked 'protected' on each of the remotes you pushed to.
NOTE: You might not have the rights to push to master on dev. Ask Dmitriy.
### **7. Publish blog for new release** ### **7. Publish blog for new release**
Merge the [blog merge request](#1-prepare-the-blog-post) in `www-gitlab-com` repository. Merge the [blog merge request](#1-prepare-the-blog-post) in `www-gitlab-com` repository.
...@@ -282,6 +278,10 @@ Include a link to the blog post and keep it short. ...@@ -282,6 +278,10 @@ Include a link to the blog post and keep it short.
Proposed email text: Proposed email text:
"We have released a new version of GitLab. See our blog post(<link>) for more information." "We have released a new version of GitLab. See our blog post(<link>) for more information."
### **10. Update installation.md**
Update [installation.md](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md) to the newest version in master and cherry-pick that commit into the stable branch.
# **23rd - Optional Patch Release** # **23rd - Optional Patch Release**
# **24th - Update GitLab.com** # **24th - Update GitLab.com**
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment