kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity
gitlab-org--gitlab-foss/doc/release/monthly.md
Dmitriy Zaporozhets b2a258722b
Modify release dates for EE and CI 
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
2014-05-02 13:23:12 +03:00

4.6 KiB
Raw Blame History

Things to do when creating new monthly minor or major release

NOTE: This is a guide for GitLab developers. If you are trying to install GitLab see the latest stable installation guide and if you are trying to upgrade, see the upgrade guides.

Install guide up to date?

  • References correct GitLab branch x-x-stable and correct GitLab shell tag?

Make upgrade guide

From x.x to x.x

0. Any major changes? Database updates? Web server change? File structure changes?

1. Make backup

2. Stop server

3. Do users need to update dependencies like git?

4. Get latest code

5. Does GitLab shell need to be updated?

6. Install libs, migrations, etc.

7. Any config files updated since last release?

Check if any of these changed since last release (~22nd of last month depending on when last release branch was created):

8. Need to update init script?

Check if changed since last release (~22nd of last month depending on when last release branch was created): https://gitlab.com/gitlab-org/gitlab-ce/commits/master/lib/support/init.d/gitlab

9. Start application

10. Check application status

Make sure the code quality indicatiors are good

  • build status on ci.gitlab.org (master branch)

  • build status on travis-ci.org (master branch)

  • Code Climate

  • Dependency Status this button can be yellow (small updates are available) but must not be red (a security fix or an important update is available)

  • Coverage Status

Release Schedule

After making the release branch new commits are cherry-picked from master. When the release gets closer we get more selective what is cherry-picked. The days of the month are approximately as follows:

  • 1-7th: Official merge window (see contributing guide).
  • 8-14th: Work on bugfixes, sponsored features and GitLab EE.
  • 15th: Code freeze
    • Stop merging into master, except essential bugfixes
    • Select a Release Manager
  • 18th: Release Candidate 1
    • Set VERSION to x.x.0.rc1
    • Create annotated tag x.x.0.rc1
    • Push the changes to GitLab.com, dev.gitlab.com, GitHub
    • Tweet about the release
    • Create a new branch on cloud for rc1
    • Deploy the new branch on Cloud after tests pass
  • 20st: Optional release candidate 2 (x.x.0.rc2, only if rc1 had problems)
  • 22nd: Release
    • Create x-x-stable branch and push to the repositories
    • QA
    • Fix anything coming out of the QA
    • Set VERSION to x.x.0
    • Create annotated tag x.x.0
    • Push VERSION + Tag to master, merge into x-x-stable
    • Publish blog for new release
    • Tweet to blog (see below)
  • 22th: release GitLab EE
  • 23nd: optional patch releases (x.x.1, x.x.2, etc., only if there are serious problems)
  • 25th: release GitLab CI

Write a blog post

  • Mention what GitLab is on the second line: GitLab is open source software to collaborate on code.
  • Select and thank the the Most Valuable Person (MVP) of this release.
  • Add a note if there are security fixes: This release fixes an important security issue and we advise everyone to upgrade as soon as possible.

Tweet

Send out a tweet to share the good news with the world. For a major/minor release, list the features in short and link to the blog post.

For a RC, make sure to explain what a RC is.

A patch release tweet should specify the fixes it brings and link to the corresponding blog post.