Merge branch 'master' of dev.gitlab.org:gitlab/gitlabhq
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com> Conflicts: CHANGELOG
This commit is contained in:
Dmitriy Zaporozhets
commit
b3b50bb86e
3 changed files with 23 additions and 21 deletions
|
|
@ -1,6 +1,7 @@
|
|||
v 7.3.0
|
||||
- Always set the 'origin' remote in satellite actions
|
||||
- Write authorized_keys in tmp/ during tests
|
||||
- Expire Rack sessions after 1 week
|
||||
|
||||
v 7.2.0
|
||||
- Explore page
|
||||
|
|
|
|||
|
|
@ -6,5 +6,6 @@ Gitlab::Application.config.session_store(
|
|||
key: '_gitlab_session',
|
||||
secure: Gitlab.config.gitlab.https,
|
||||
httponly: true,
|
||||
expire_after: 1.week,
|
||||
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'
|
|||
|
||||
Merge the RC1 EE code into GitLab.com.
|
||||
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.
|
||||
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.
|
|||
|
||||
`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
|
||||
|
|
@ -221,22 +229,7 @@ git checkout -b x-x-stable
|
|||
git push <remote> x-x-stable
|
||||
```
|
||||
|
||||
### **2. 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.
|
||||
|
||||
### **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**
|
||||
### **3. 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,
|
||||
|
||||
|
|
@ -246,12 +239,17 @@ git tag -a vx.x.0 -m 'Version x.x.0' xxxxx
|
|||
|
||||
where `xxxxx` is SHA-1.
|
||||
|
||||
### **5. Push the tag**
|
||||
### **4. Push the tag**
|
||||
|
||||
```
|
||||
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**
|
||||
|
||||
For GitLab CE, push to dev, GitLab.com and GitHub.
|
||||
|
|
@ -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.
|
||||
|
||||
NOTE: You might not have the rights to push to master on dev. Ask Dmitriy.
|
||||
|
||||
### **7. Publish blog for new release**
|
||||
|
||||
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.
|
|||
Proposed email text:
|
||||
"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**
|
||||
|
||||
# **24th - Update GitLab.com**
|
||||
|
|
|
|||
Loading…
Reference in a new issue