summaryrefslogtreecommitdiffstats
path: root/Documentation/dev-release.txt
blob: 5ea3042090fffb0389a70a63c91c008c28414f97 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
Making a Gerrit Release
=======================

[NOTE]
========================================================================
This document is meant primarily for Gerrit maintainers
who have been given approval and submit status to the Gerrit
projects.  Additionally, maintainers should be given owner
status to the Gerrit web site.
========================================================================

To make a Gerrit release involves a great deal of complex
tasks and it is easy to miss a step so this document should
hopefuly serve as both a how to for those new to the process
and as a checklist for those already familiar with these
tasks.


Gerrit Release Type
-------------------

Here are some guidelines on release approaches depending on the
type of release you want to make (stable-fix, stable, RC0, RC1...).

Stable
~~~~~~

A stable release is generally built from the master branch and may need to
undergo some stabilization before releasing the final release.

* Propose the release with any plans/objectives to the mailing list

* Create a Gerrit RC0

* If needed create a Gerrit RC1

[NOTE]
========================================================================
You may let in a few features to this release
========================================================================

* If needed create a Gerrit RC2

[NOTE]
========================================================================
There should be no new features in this release, only bug fixes
========================================================================

* Finally create the stable release (no RC)


Stable-Fix
~~~~~~~~~~

Stable-fix releases should likely only contain bug fixes and doc updates.

* Propose the release with any plans/objectives to the mailing list

* This type of release does not need any RCs, release when the objectives
  are met



Create the Actual Release
---------------------------

In the example commands below we assume that the last release was '2.4' and that
we are preparing '2.5' release.

Prepare the Subprojects
~~~~~~~~~~~~~~~~~~~~~~~

* Publish the latest snapshot for all subprojects
* Freeze all subprojects and link:dev-release-subproject.html[publish]
  them!


Prepare Gerrit
~~~~~~~~~~~~~~

* Create a `stable-2.5` branch for making the new release

* In the `master` branch: Update the poms for the Gerrit version, push for
review, get merged

====
 tools/version.sh --snapshot=2.5
====

* Checkout the `stable-2.5` branch
* Update the top level `pom.xml` in Gerrit to ensure that none of the
Subprojects point to snapshot releases

* Tag

====
 git tag -a -m "gerrit 2.5-rc0" v2.5-rc0
 git tag -a -m "gerrit 2.5" v2.5
====

* Build (without plugins)

====
 ./tools/release.sh
====

[[plugin-api]]
Publish the Plugin API JAR File
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* Push JAR to `commondatastorage.googleapis.com`
** Run `tools/deploy_api.sh`

Prepare the Core Plugins
~~~~~~~~~~~~~~~~~~~~~~~~
* link:dev-release-subproject.html[Release and publish] the core plugins

Package Gerrit with Plugins
~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Ensure that the core plugins listed in `gerrit-package-plugins/pom.xml`
point to the latest release version (no dependency to snapshot versions)
* Include core plugins into WAR
====
 $ ./tools/version.sh --release && mvn clean package -f gerrit-package-plugins/pom.xml
 $ ./tools/version.sh --reset
====

* Find WAR that includes the core plugins at
`gerrit-package-plugins\target\gerrit-full-v2.5.war`
* Sanity check WAR

Publish to the Project Locations
--------------------------------

WAR File
~~~~~~~~

* Upload WAR to code.google.com/p/gerrit (manual web browser)
** Go to http://code.google.com/p/gerrit/downloads/list
** Use the "New Download" button

* Update labels:
** new war: [release-candidate], featured...
** old war: deprecated

Tag
~~~

* Push the New Tag

====
 git push gerrit-review refs/tags/v2.5-rc0:refs/tags/v2.5-rc0
 git push gerrit-review refs/tags/v2.5:refs/tags/v2.5
====


Docs
~~~~

====
 make -C Documentation PRIOR=2.4 update
 make -C ReleaseNotes update
====

(no +PRIOR=+... if updating the same release again during RCs)

* Update Google Code project links
** Go to http://code.google.com/p/gerrit/admin
** Point the main page to the new docs. The link to the documentation has to be
updated at two places: in the project description and also in the Links
section.
** Point the main page to the new release notes

[NOTE]
========================================================================
The docs makefile does an svn cp of the prior revision of the docs to branch
the docs so you have less to upload on the new docs.

User and password from here:

    https://code.google.com/hosting/settings

If subversion assumes a different username than your google one and asks for a
password right away simply hit enter. Subversion will fail and then ask for
another username and password. This time enter the username and password from
the page linked above. After that subversion should save the username/password
somewhere under `~/.subversion/auth` folder.
========================================================================


Issues
~~~~~~

====
 How do the issues get updated?  Do you run a script to do
 this?  When do you do it, after the final 2.2.2 is released?
====

By hand.

Our current process is an issue should be updated to say Status =
Submitted, FixedIn-2.2.2 once the change is submitted, but before the
release.

After the release is actually made, you can search in Google Code for
``Status=Submitted FixedIn=2.2.2'' and then batch update these changes
to say Status=Released. Make sure the pulldown says ``All Issues''
because Status=Submitted is considered a closed issue.


Mailing List
~~~~~~~~~~~~

* Send an email to the mailing list to announce the release, consider including some or all of the following in the email:
** A link to the release and the release notes (if a final release)
** A link to the docs
** Describe the type of release (stable, bug fix, RC)

----
To: Repo and Gerrit Discussion <repo-discuss@googlegroups.com>
Subject: Announce: Gerrit 2.2.2.1  (Stable bug fix update)

I am pleased to announce Gerrit Code Review 2.2.2.1.

Download:

  http://code.google.com/p/gerrit/downloads/list


This release is a stable bug fix release with some
documentation updates including a new "Contributing to
Gerrit" doc:

  http://gerrit-documentation.googlecode.com/svn/Documentation/2.2.2/dev-contributing.html


To read more about the bug fixes:

  http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.2.2.1.html

-Martin
----

* Add an entry to the NEWS section of the main Gerrit project web page
** Go to: http://code.google.com/p/gerrit/admin
** Add entry like:
----
 * Jun 14, 2012 - Gerrit 2.4.1 [https://groups.google.com/d/topic/repo-discuss/jHg43gixqzs/discussion Released]
----

* Update the new discussion group announcement to be sticky
** Go to: http://groups.google.com/group/repo-discuss/topics
** Click on the announcement thread
** Near the top right, click on options
** Under options, cick the "Display this top first" checkbox
** and Save

* Update the previous discussion group announcement to no longer be sticky
** See above (unclick checkbox)


Merging Stable Fixes to master
------------------------------

After every stable-fix release, stable should be merged to master to
ensure that none of the fixes ever get lost.

====
 git config merge.summary true
 git checkout master
 git reset --hard origin/master
 git branch -f stable origin/stable
 git merge stable
====


GERRIT
------
Part of link:index.html[Gerrit Code Review]