Show last authors
1 {{box cssClass="floatinginfobox" title="**Contents**"}}
2 {{toc/}}
3 {{/box}}
4
5 Contains instructions to perform various release steps in the [[Release Plans>>ReleasePlans.WebHome]].
6
7 {{id name="HInitialCLIRRcheck"/}}
8
9 = Initial Backward Compatibility Check =
10
11 This initial step checks if the previous release cycle, or more recent bugfix releases done since, have properly set the ##xwiki.compatibility.previous.version## property in the [[top level POM of ##xwiki-commons##>>https://github.com/xwiki/xwiki-commons/blob/master/pom.xml]] (for the branch you are currently releasing).
12
13 For example, if the current release to be made is for ##4.2-milestone-3## and, in the meanwhile, there have been released bugfix versions for 4.1 (4.1.4 being the latest released), you need to ensure that the value for ##xwiki.compatibility.previous.version## is ##4.1.4##.
14
15 = Verify JIRA issue =
16
17 If there are opened JIRA issues for the version you are currently releasing (##fixVersion## is set to the current release), you have two options:
18
19 1. The issue has no code committed yet (Commits tab shows nothing). In this case, you need to push the issue to the next development version. (e.g. ##fixVersion## = 6.3-milestone-1 will be moved to ##fixVersion## = 6.3-milestone-2)
20 1. There is some code already committed (Commits tab is not empty). In this case, you need to contact the assigned developer of the issue and find out if the committed code is complete:
21 11. If the code is complete, you can close the issue (or ask the dev to do it)
22 11. If the code is not complete, you can close the issue and ask the dev to create a new issue for the remaining work to be done for the next version.
23
24 In all cases, all opened issues must be closed before the release can be done.
25
26 = Verify issues with commits =
27
28 Such open issues may exist because the wrong issue key was used when committing, the existing commits are just trying to fix a test or adding extra logging (and not affecting the runtime) while the problem has not been addressed, it's a commit in a feature branch, etc. You need to ignore these false positives and detect any issue that has actual work done on it that is relevant for this release, close it and assign it the correct fix version so that it's properly counted in the release notes.
29
30 Note: The JIRA query is not perfect yet as we [[cannot query on the commit update date>>https://jira.atlassian.com/browse/JRASERVER-64130]]. Thus FTM you'll need to review each issue listed and verify if the issue should be closed or if it's a false positive.
31
32 = Log on Release machine =
33
34 {{code language="sh"}}
35 # Get on the maven CI master machine
36 [email protected]:~$ ssh [email protected]
37
38 # Get on the agent machine
39 [email protected]:~$ a1-1
40 {{/code}}
41
42 = Set up your identity =
43
44 == The first time ==
45
46 * [[Configure your Github profile to add the SSH key of the agent>>https://github.com/settings/ssh]] so that the commits can be pushed to Github with your user (To get the agent SSH key, do {{code language="sh"}}cat ~/.ssh/id_rsa.pub{{/code}}). To verify it works, do the following on the agent machine: {{code language="sh"}}ssh -T [email protected]{{/code}}. It should reply with ##Hi <your user id>! You've successfully authenticated, but GitHub does not provide shell access.##.
47 * [[Create your own GPG key>>http://fedoraproject.org/wiki/Creating_GPG_Keys]] if you don't already have one: {{code language="sh"}}gpg --gen-key{{/code}}
48 * [[Publish your public GPG key>>http://blog.sonatype.com/2010/01/how-to-generate-pgp-signatures-with-maven/#BLOG-108SignArtifacts,IntegrateMavenandGPG-DistributeYouPublicKey]], if you have not already done so: {{code language="sh"}}gpg --keyserver hkp://pool.sks-keyservers.net --send-key <keyID>{{/code}}
49 * Import your GPG key:
50 ** On your local computer run: {{code language="sh"}}gpg --list-secret-keys{{/code}}
51 ** Export your key in a ##secret.key## file: {{code language="sh"}}gpg --export-secret-keys «keyID» > secret.key{{/code}} where ##keyID## is the 8 characters long hexadecimal string on the ##sec## line
52 ** Copy the ##secret.key## file to the agent machine (you may need to copy to ##maven.xwiki.org## first and then to agent-1-1)
53 *** From your local computer, upload the key to ##maven.xwiki.org##: {{code language="sh"}}scp secret.key [email protected]:/home/maven{{/code}}
54 *** From ##maven.xwiki.org## (/home/maven): {{code language="sh"}}scp secret.key a1-1:/home/hudsonagent/<yourname>.gpgkey{{/code}} (give it a name)
55 **** The key can be stored on the agent, since it's password protected, so that you don't have to upload it next time, and just re-import it.
56 **** TODO: find out how we can keep the keys imported and tell maven which one to use during the release.
57 *** Remove the key from ##maven.xwiki.org## after you have uploaded it to agent-1-1: {{code language="sh"}}rm secret.key{{/code}}
58 ** On the agent machine, run {{code language="sh"}}gpg --import <yourname>.gpgkey{{/code}}
59 * You need to have a ##.gitconfig.<yourusername>## file. You can do that by copying one of the existing ##gitconfig## file
60 * Make sure your ##gitconfig## file has the key ##signingkey## in the ##[user]## section (the value is your key id which you can get with {{code language="sh"}}gpg --list-secret-keys{{/code}}).
61 * Copy your ##.gitconfig.<yourusername>## file as the main ##gitconfig## file: {{code language="sh"}}cp .gitconfig.<yourusername> .gitconfig{{/code}}
62
63 == The other times ==
64
65 * [[Configure your Github profile to add the SSH key of the agent>>https://github.com/settings/ssh]] so that the commits can be pushed to Github with your user (To get the agent SSH key, do {{code language="sh"}}cat ~/.ssh/id_rsa.pub{{/code}}). To verify it works, do the following on the agent machine: {{code language="sh"}}ssh -T [email protected]{{/code}}. It should reply with ##Hi <your user id>! You've successfully authenticated, but GitHub does not provide shell access.##.
66 * Make sure previous release manager did not left his GPG key
67 {{code language="sh"}}gpg --delete-secret-and-public-keys `gpg --list-secret-keys | grep ^sec | cut -d/ -f2 | cut '-d ' -f1`{{/code}}
68 * Import your GPG key, run {{code language="sh"}}gpg --import <yourname>.gpgkey{{/code}}
69 ** If you did not leave your secret key file on the agent machine, you have to re-upload it (see [[The first time>>||anchor="HThefirsttime"]] section above).
70 * Copy your ##.gitconfig.<yourusername>## file as the main ##gitconfig## file: {{code language="sh"}}cp .gitconfig.<yourusername> .gitconfig{{/code}}
71
72 === Script to automatize this step ===
73
74 1. Put this script on your local machine.
75 1. Replace the ##USER_NAME## variable.
76 1. Make sure you have exported your secret key in a file called ##secret.key## in your user directory.
77 1. Don't forget to give execution right to the file.
78 1. Execute and enjoy!
79
80 {{code language="sh"}}
81 #!/bin/bash
82
83 USER_NAME='gdelhumeau'
84
85 function log {
86 ## Colors
87 RESET_TEXT_COLORS='\033[0m'
88 GREEN_TEXT='\033[1;32m'
89 BLACK_BACKGROUND='\033[40m'
90
91 echo -e "${GREEN_TEXT}${BLACK_BACKGROUND}* $1${RESET_TEXT_COLORS}"
92 }
93
94 log "Copy secret key to the maven machine"
95 scp ~/secret.key "[email protected]:/home/maven/${USER_NAME}.key"
96
97 log "Put it on the agent1-1"
98 ssh [email protected] "scp /home/maven/${USER_NAME}.key a1-1:/home/hudsonagent"
99
100 log "Delete it from maven.xwiki.org"
101 ssh [email protected] "rm /home/maven/${USER_NAME}.key"
102
103 log "Import the key in agent1-1"
104 ssh [email protected] "ssh a1-1 'gpg --import /home/hudsonagent/${USER_NAME}.key'"
105
106 log "Delete it from agent1-1"
107 ssh [email protected] "ssh a1-1 'rm /home/hudsonagent/${USER_NAME}.key'"
108
109 log "Copy gitconfig"
110 ssh [email protected] "ssh a1-1 'cp /home/hudsonagent/.gitconfig.${USER_NAME} /home/hudsonagent/.gitconfig'"
111
112 log "Display agent1-1 SSH key (to put on https://github.com/settings/keys)"
113 printf "\033[0;91m\033[0;100m"
114 ssh [email protected] "ssh a1-1 'cat /home/hudsonagent/.ssh/id_rsa.pub'"
115
116 log "Connect to hudsonagent"
117 ssh -tt [email protected] "ssh -tt a1-1"
118 {{/code}}
119
120 = Update Release scripts =
121
122 {{code language="sh"}}
123 # Update the release script
124 [email protected]:~$ cd xwiki-dev-tools ; git pull --rebase ; cd ..
125 {{/code}}
126
127 {{info}}
128 Do a ##git status## to verify that there are not any committed but not pushed stuff lying around...
129 {{/info}}
130
131 = Configure the Java Version =
132
133 Depending on which branch you are releasing from you may have to use a different Java version than what is used on master. To change the Java version you need to remove the "java" symbolic link from the home folder and recreate it to point to the "javaX" folder that corresponds to the Java version you have to use.
134
135 {{code language="sh"}}
136 # See what Java versions are available.
137 [email protected]:~$ ls -al | grep java
138 # Change the Java version
139 [email protected]:~$ rm java
140 [email protected]:~$ ln -s java7 java
141 # See if the change has been taken into account.
142 [email protected]:~$ java -version
143 {{/code}}
144
145 = Update Translations =
146
147 {{warning}}
148 When you release a .x version (bug fix release), be very careful when you update translations because the new ones might concern new stuff introduced in the master branch. The issue is that the translations platform does not support branches (translations are coming from master).
149 {{/warning}}
150
151 For a **release candidate**, the translations were already merged (when the Pull Requests were accepted) into the master branch which you have just forked.
152
153 For a **final version**, there may be translations added since the RC that we need to integrate. Perform the following steps:
154
155 * Move to ##xwiki-trunks##:(((
156 {{code language="sh"}}
157 [email protected]:~$ cd releases/xwiki-trunks/
158 {{/code}}
159 )))
160 * Run the update goal of the script with your branch (e.g. stable-10.5.x):(((
161 {{code language="sh"}}
162 [email protected]:~/releases/xwiki-trunks$ ~/xwiki-dev-tools/weblate-scripts/apply_translations.sh update stable-10.5.x
163 {{/code}}
164 )))
165 * Review the changes for anything amiss.
166 ** You need to go through each project (##xwiki-commons##, ##xwiki-rendering##, ##xwiki-platform##)
167 ** Do a {{code}}git status{{/code}} to spot changes.
168 *** Do a {{code}}git diff --cached{{/code}} and visually review modified translation keys and spot problems (like spam). Do not spend too much time here, since major issues should have been reviewed by the committer that merged the Pull Request, a quick scan is enough to spot obvious problems.
169 *** No need to do a {{code}}git add{{/code}} at this point since it will be done for all projects below.
170 * Push / commit the translation changes on the branch of the version you are releasing (e.g. stable-10.5.x):(((
171 {{code language="sh"}}
172 [email protected]:~/releases/xwiki-trunks$ ~/xwiki-dev-tools/weblate-scripts/apply_translations.sh push stable-10.5.x
173 {{/code}}
174 )))
175
176 = Compute list of updated languages =
177
178 Collect the **list of updated languages** to publish in the Release Notes:
179
180 * ##cd## to each repository (##xwiki-commons##, ##xwiki-rendering##, ##xwiki-platform##)
181 * Run the ##list_translation_changes.sh## script to list all relevant modified translation files since the previously released **final** version and generate the list of modified languages (notice the usage of the ##~-~-diff## parameter to help you decide if a translation language should be counted or not, see below for more details):(((
182 {{code language="bash"}}
183 ## list_translation_changes.sh start_commit end_commit [options]
184
185 ## Example when releasing a final version (e.g. 10.7):
186 [email protected]:~/releases/xwiki-trunks/xwiki-commons$ ~/xwiki-dev-tools/weblate-scripts/list_translation_changes.sh xwiki-commons-10.6.1 stable-10.7.x --diff | more
187 ## Example when releasing a RC version (e.g. 10.7RC1):
188 [email protected]:~/releases/xwiki-trunks/xwiki-commons$ ~/xwiki-dev-tools/weblate-scripts/list_translation_changes.sh xwiki-commons-10.6.1 xwiki-commons-10.7-rc-1 --diff | more
189
190 ## Other examples on some already released versions (in case the need arises):
191 [email protected]:~/releases/xwiki-trunks/xwiki-rendering$ ~/xwiki-dev-tools/weblate-scripts/list_translation_changes.sh xwiki-rendering-10.3 xwiki-rendering-10.4 --diff | more
192 [email protected]:~/releases/xwiki-trunks/xwiki-platform$ ~/xwiki-dev-tools/weblate-scripts/list_translation_changes.sh xwiki-platform-10.3 xwiki-platform-10.4 --diff | more
193 {{/code}}
194 )))
195 * Merge the list of updated language codes across all the repositories (from the output of the commands above) and update the Release Notes in the ##Translations## section with these language codes.
196 ** Only count what should be counted:(((
197 {{error}}
198 Be careful to only count real translation changes. For example if Weblate reorder the translations but no new translation is added, the language should not be counted.
199
200 At the moment the script keeps all changes of the type `<start of line>key=value`, i.e. it discard comments for ex `#Missing someKey=someValue` is not counted.
201
202 Since it can be hard to figure out what are user changes when there are key renames, key deletions or key move, another way to view changes is to look at the [[Activity Stream on l10n for added or changed translations>>https://l10n.xwiki.org/changes/?project=xwiki-platform&lang=&action=5&action=2]].
203
204 {{/error}}
205 )))
206 ** Skip duplicates and sort the final list alphabetically.
207
208 {{warning}}
209 If the flag for a translation is missing, add it to [[xwiki:Macros.Language]].
210 {{/warning}}
211
212 = Build the release =
213
214 {{toc scope="local"/}}
215
216 {{info}}
217 Tip: running the release script will first ask you for your GPG key passphrase. If you mistype or enter a wrong passphrase, the release will fail to perform. You can test your passphrase locally running the following command :
218
219 {{code language="sh"}}echo "test" | gpg --no-use-agent -o /dev/null --local-user <KEYID> -as - && echo "Passphrase is correct"{{/code}}
220
221 If for a reason or another you've made a mistake typing your passphrase in, you will need to delete (locally on the agent machine) the release branch and created tag before you can start over again.
222 {{/info}}
223
224 {{info}}
225 In general the answer to **What is the next SNAPSHOT version?** is ##<next version in that branch>-SNAPSHOT##. Here are some examples:
226 * when releasing ##10.10-rc-1## the answer is ##10.10-SNAPSHOT##
227 * when releasing ##10.10## the answer is ##10.10.1-SNAPSHOT##
228 * when releasing ##10.10.1## the answer is ##10.10.2-SNAPSHOT##
229
230 When releasing a ##Release Candidate## (e.g. 6.2-rc-1), make sure that, when asked **What is the next SNAPSHOT version?**, you do not increment the snapshot version (i.e. you answer **6.2-SNAPSHOT** instead of 6.3-SNAPSHOT or whatever suggestion you have). This is because the next step will ask you to create a stable branch where the final version (if this is the last RC we`re doing) will be released and there we need to keep the SNAPSHOT version to the current one.
231
232 If you have created the stable branch and are asked **What is the next master version?**, you will now increment the snapshot version (i.e. answer **6.3-SNAPSHOT**) so that the master branch can move to the next development version.
233 {{/info}}
234
235 {{info}}
236 Tip: Because the build process is a lenghty one (currently around 2 hours), it is a good idea to use the [[screen linux command>>http://www.rackaid.com/resources/linux-screen-tutorial-and-how-to/]]. This is most helpful in case your Internet connection or electrical power drops. However, it is not in any way mandatory to use screen during the release.
237 {{/info}}
238
239 {{code language="sh"}}
240 # Perform the release from the release sources
241 [email protected]:~/releases/xwiki-trunks$ ~/maven-release.sh
242 {{/code}}
243
244 == Restart the release ==
245
246 If the build failed or if you wish to release again, perform the following steps:
247
248 * Set the version that you're building, e.g. {{code language="sh"}}[email protected]:~/releases/xwiki-trunks$ export VERSION='4.2-milestone-3'{{/code}}
249 * Navigate to the repositories that failed to build (e.g. ##xwiki-platform##) and clean up. For example for ##xwiki-platform##:(((
250 {{code language="sh"}}
251 [email protected]:~/releases/xwiki-trunks$ cd xwiki-platform
252 [email protected]:~/releases/xwiki-trunks/xwiki-platform$ ~/restart-release.sh
253 {{/code}}
254 )))
255 * Edit the ##maven-release.sh## script and comment out the previously successfully released repositories so that you don't release them again.(((
256 {{code language="sh"}}
257 [email protected]:~/releases/xwiki-trunks/xwiki-platform$ cd ..
258 [email protected]:~/releases/xwiki-trunks$ vim ~/maven-release.sh
259 {{/code}}
260
261 Go to the end of the ##maven-release.sh## file and scroll up, until you reach this section:
262
263 {{code language="sh"}}
264 # Wrapper function that calls release_project for each XWiki project in order: commons, rendering, platform, enterprise, manager.
265 # This is the main function that is called when running the script.
266 function release_all() {
267 ...
268 {{/code}}
269
270 Inside this method, comment out the previously successful top level projects and leave uncommented the top level projects that still need to be released, including the one we are resuming from. In this example, we are resuming from ##xwiki-platform## but ##xwiki-commons## and ##xwiki-rendering## were already successfully released, so we are skipping them:
271
272 {{code language="sh"}}
273 ...
274 echo "*****************************"
275 echo -e "\033[1;32m Releasing xwiki-commons\033[0m"
276 echo "*****************************"
277 # release_project xwiki-commons
278 echo "*****************************"
279 echo -e "\033[1;32m Releasing xwiki-rendering\033[0m"
280 echo "*****************************"
281 # release_project xwiki-rendering
282 echo "*****************************"
283 echo -e "\033[1;32m Releasing xwiki-platform\033[0m"
284 echo "*****************************"
285 release_project xwiki-platform
286 ...
287 {{/code}}
288 )))
289 * Fix the build if need be (you won't need to fix anything if you just want to release again for example).
290 * Re-launch the ##maven-release.sh## script from ##/releases/xwiki-trunks## to resume from where we left off:(((
291 {{code language="sh"}}
292 [email protected]:~/releases/xwiki-trunks$ ~/maven-release.sh
293 {{/code}}
294 )))
295
296 === If the release:prepare is good and you need to restart only the release:perform ===
297
298 {{warning}}
299 The instructions below are **not applicable for RC releases** (that involve working with other branches than ##master## and other additional operations). Would need additional steps to be complete, so it`s safer to just restart from the top level project that failed (i.e. rendering, platform, etc.).
300 {{/warning}}
301
302 Going even further with the resuming of a failed build, in the case of release:perform, we can resume from the actual failed module. To do so, we must make some additional temporary modifications to the release script, besides the one described above which isolates the script to release only the currently failed module.
303
304 {{warning}}
305 This method only applies to a **single failed project** at a time (e.g. xwiki-platform). Make sure all other projects are **commented out** in the ##release_all## method.
306
307 Do **not** run the ##~~/restart-release.sh## command on the failed module because ##release:perform## needs that information to be able to resume. Also, remember to cleanup after finishing with the release of the project at hand.
308 {{/warning}}
309
310 Comment out the cleanup steps done in the ##release_project## method:
311
312 {{code language="sh"}}
313 function release_project() {
314 cd $1
315 # pre_cleanup
316 # update_sources
317 # check_branch
318 # create_release_branch
319 # pre_update_parent_versions
320 release_maven
321 post_update_parent_versions
322 push_release
323 ...
324 {{/code}}
325
326 Comment out the ##release:prepare## step in the ##release_maven## method and add the ##-rf group:artefactId## parameter inside the -Darguments="..." with the module you want to resume the release from. See an example below where we are resuming from ##org.xwiki.platform:xwiki-platform-distribution-war##.
327
328 {{code language="sh"}}
329 function release_maven() {
330 DB_PROFILE=hsqldb
331
332 echo -e "\033[0;32m* release:prepare\033[0m"
333 # mvn release:prepare -DpushChanges=false -DlocalCheckout=true -DreleaseVersion=${VERSION} -DdevelopmentVersion=${NEXT_SNAPSHOT_VERSION} -Dtag=${TAG_NAME} -DautoVersionSubmodules=true -Phsqldb,mysql,pgsql,derby,jetty,glassfish,legacy,integration-tests,office-tests,standalone -Darguments="-N ${TEST_SKIP}" ${TEST_SKIP} || exit -2
334
335 echo -e "\033[0;32m* release:perform\033[0m"
336 mvn release:perform -DpushChanges=false -DlocalCheckout=true -P${DB_PROFILE},jetty,legacy,integration-tests,office-tests,standalone ${TEST_SKIP} -Darguments="-P${DB_PROFILE},jetty,legacy,integration-tests,office-tests ${TEST_SKIP} -Dgpg.passphrase='${GPG_PASSPHRASE}' -Dxwiki.checkstyle.skip=true -rf org.xwiki.platform:xwiki-platform-distribution-war" -Dgpg.passphrase="${GPG_PASSPHRASE}" || exit -2
337
338 echo -e "\033[0;32m* Creating GPG-signed tag\033[0m"
339 ...
340 {{/code}}
341
342 Manually set the git tag name that will be used for GPG signing:
343
344 {{code language="sh"}}
345 ## The format is MODULE_NAME-VERSION. Modify accordingly.
346 export TAG_NAME="xwiki-platform-8.3-milestone-2"
347 {{/code}}
348
349 Run the release script to resume the release of the current project:
350
351 {{code language="sh"}}
352 [email protected]:~/releases/xwiki-trunks/xwiki-platform$ ~/maven-release.sh
353 {{/code}}
354
355 {{warning}}
356 **Cleanup** the release script by removing the temporary changes described in this section. This applies if you want to proceed to the next project (e.g. xwiki-enterprise) where the release needs to be executed properly.
357 {{/warning}}
358
359 = Generate Code Contributors list =
360
361 {{info}}
362 * The following commands should be performed on the agent machine, after running the build (but can be run locally as well).
363 * If you're releasing a final version, also include the contributors for the RC.
364 {{/info}}
365
366 * Automatically, on the agent:(((
367 {{code language="bash"}}
368 ## list_contributors.sh <start_version> <end_version>
369 [email protected]:~/releases/xwiki-trunks$ ~/list_contributors.sh 10.4 10.5-rc-1
370 {{/code}}
371 )))
372 * Manually (on the agent or locally, if the automatic option fails):
373 ** Collect the list of code contributors for this release by running the following command on each branch on each repository that has been released (##xwiki-commons##, ##xwiki-rendering##, ##xwiki-platform##):(((
374 {{code language="bash"}}
375 > git fetch --tags
376 > git log --pretty=format:"%an" <previousTag>..<nextTag> | sort -u
377 ## Example:
378 > git log --pretty=format:"%an" xwiki-commons-10.4..xwiki-commons-10.5-rc1 | sort -u
379 > git log --pretty=format:"%an" xwiki-rendering-10.4..xwiki-rendering-10.5-rc1 | sort -u
380 > git log --pretty=format:"%an" xwiki-platform-10.4..xwiki-platform-10.5-rc1 | sort -u
381 ## For **final versions**, always compare with the previous final, not with the previous RC:
382 > git log --pretty=format:"%an" xwiki-platform-10.4..xwiki-platform-10.5 | sort -u
383 {{/code}}
384 )))
385 * Try to remove duplicates and infrastructure users (like ##xwikirogci## or ##XWiki##) and sort alphabetically.
386 * Update the Release Notes in the Credits section with the contributors list.
387
388 = Handle Backward Compatibility Actions =
389
390 == Update Backward Compatibility in the release note ==
391
392 The Backward Compatibility report is automatically generated in the Release Notes page by the ##~{~{backwardCompatiblityReport version="<version>"/}}## macro which does the following:
393
394 * Gets the revapi ignores from the ##pom.xml## of ##xwiki-commons##, ##xwiki-rendering## and ##xwiki-platform## GitHub repositories and store them in an xobject in the Release Note page. If you wish to regenerate the content from GitHub just delete this xobject.
395 * Displays the ignores
396
397 == Update the backward compatibility setup in the build ==
398
399 If you're releasing a **final or bugfix**, perform the following operations on the agent or on your local machine:
400
401 * (((
402 Automatically, on the agent:
403
404 (((
405 {{code}}
406 ## backward_compatibility_cleanup.sh <new_version>
407 [email protected]:~/releases/xwiki-trunks$ ~/backward_compatibility_cleanup.sh 12.3
408 ...
409 ...
410 ...
411 Also update the [master] branch? (Only if new release version is 'bigger' than the existing one. Y for final, N for most bugfixes except bugfix of a very recent final) :
412 [y/N]
413 {{/code}}
414 )))
415
416 * When asked **Also update the [master] branch?**, only answer {{code}}y{{/code}} (##yes##) in one of these 2 cases, otherwise answer {{code}}N{{/code}} (##no##):(((
417 1. (common) if you are releasing a **final version** (e.g. 12.3, from stable-12.3.x that was recently created by the release candidate that was released 2 weeks ago) OR
418 1. (less common) if you are releasing a //bugfix version that would be "bigger"// than any existing version (e.g. 12.3 was just released, or even 12.3-rc-1, however, a critical bug was discovered and we quickly release the bugfix version ##12.3.1##. For this bugfix, you also need to update master, because it acts more like a final version than a bugfix and is 'bigger' than what was released until then.)
419 )))
420 )))
421 * Manually (on the agent or locally, if the automatic option fails):
422 ** Checkout ##master## for ##xwiki-commons## and edit the top level ##pom.xml## to update the ##xwiki.compatibility.previous.version##. Set the value to be your release you've just done.(((
423 {{code}}
424 ## Replace the previous version with the new version (e.g. 10.4 with 10.5).
425 [email protected]:~/releases/xwiki-trunks/xwiki-commons$ git checkout master
426 [email protected]:~/releases/xwiki-trunks/xwiki-commons$ sed -i 's/<xwiki.compatibility.previous.version>.*</<xwiki.compatibility.previous.version>10.5</' pom.xml
427 ## Double check that it has been updated
428 [email protected]:~/releases/xwiki-trunks/xwiki-commons$ git diff
429 ## Commit and push
430 [email protected]:~/releases/xwiki-trunks/xwiki-commons$ git commit -a -m "[release] Updated compatibility previous version to the one just released."
431 [email protected]:~/releases/xwiki-trunks/xwiki-commons$ git push origin master
432 {{/code}}
433 )))
434 ** On ##master##, you have to remove ignores from 3 locations and then commit & push the changes (##git commit -a -m "[Misc] Removed revapi ignores from the previous version"##):
435 *** ##xwiki-commons/xwiki-commons-core/pom.xml##
436 *** ##xwiki-rendering/pom.xml##
437 *** ##xwiki-platform/xwiki-platform-core/pom.xml##
438 *** If you are doing this on the agent, you can use ##nano## to open the files and use ##CTRL+W## to search for ##revapi##. Once you have found the JSON formatted ignores, select all the lines you want to delete by using ##CTRL+SHIFT+6## and press ##CTRL+K## to delete the selected lines. Exit the exitor with ##CTRL+X##, ##y##, ##ENTER## (when asked if the changes should be saved) and commit the changes for each repository.
439 ** Make sure the ##xwiki.compatibility.previous.version## value is changed also on the branch from where you've released, and that the ignores are cleaned too from the branch, since future releases (ex. 10.5.1) are final releases too.
440
441 = Clean up identity =
442
443 {{code language="sh"}}
444 # Git identity
445 [email protected]:~/releases/xwiki-trunks$ cd
446 [email protected]:~$ cp .gitconfig.default .gitconfig
447
448 # GPG key
449 [email protected]:~$ gpg --delete-secret-and-public-keys `gpg --list-secret-keys | grep ^sec | cut -d/ -f2 | cut '-d ' -f1`
450
451 # Local changes to the release-scripts (maven-release.sh, user/password in release-translations.sh, etc.)
452 [email protected]:~$ cd xwiki-dev-tools
453 # Double check that you are not removing any improvement you have made to the release scripts that should be committed instead ;)
454 [email protected]:~/xwiki-dev-tools$ git status
455 [email protected]:~/xwiki-dev-tools$ git diff
456 [email protected]:~/xwiki-dev-tools$ git checkout .
457 {{/code}}
458
459 (!) Then don't forget to [[remove the Agent's SSH Key from your Github Account>>https://github.com/settings/ssh]].
460
461 {{id name="HGenerateCLIRRReport"/}}
462
463 {{id name="HGenerateBackwardCompatibilityReport"/}}
464
465 = Blog post on xwiki.org =
466
467 [[Create a new blog post on xwiki.org>>xwiki:Blog.WebHome]]. You can have a look at the [[previous release blog posts>>xwiki:Blog.Releases]] for inspiration.
468
469 {{comment}}
470 In order to display the new blog post in the "Latest Blog Posts" sections of the xwiki.org homepage, you need to **refresh the document cache** that is currently used. To do that, [[edit the macro object's code>>http://www.xwiki.org/xwiki/bin/edit/XWikiOrgCode/LatestBlogPosts?editor=object&classname=XWiki.WikiMacroClass&object=0&property=code]], look for the "cache" macro call and modify the "id" parameter's value (for instance from "latestBlogPostsCache3" to "latestBlogPostsCache4"). This will trigger a refresh on the homepage and the new blog post will be listed.
471 {{/comment}}
472
473 = Update Wikimatrix =
474
475 This step must be performed only for the latest final releases (not bugfixes or RCs).
476
477 If it's the first time please register on https://www.wikimatrix.org and ask someone (Thomas for example) to get admin access to XWiki project for you.
478
479 Note: The only exception when a bugfix would be added here is when it would be done for the latest released final version (e.g. latest final is 10.2 and the bugfix is 10.2.1).
480
481 = Forum Announcement =
482
483 * Add a new post to the users forum on https://forum.xwiki.org/c/News
484 * Example post:
485 ** Subject: {{code language="none"}}XWiki <version> released{{/code}}
486 ** Content:(((
487 {{code language="none"}}
488 The XWiki development team is proud to announce the availability of XWiki <version>.
489 <short summary>
490
491 You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download
492
493 Make sure to review the release notes:
494 https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/<short version>
495
496 Thanks for your support
497 -The XWiki dev team
498 {{/code}}
499 )))
500 ** Category: {{code language="none"}}News & Events{{/code}}
501 ** Tags: {{code language="none"}}release{{/code}}
502
503 = Announce on Twitter =
504
505 To announce the new release on Twitter using [[XWiki.org`s account>>https://twitter.com/xwikiorg]]. Use the following type of text:
506
507 {{code language="bash"}}
508 [email protected]:~$ twidge update "#XWiki 8.4.1 has been #released! Check it out: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/8.4.1"
509 {{/code}}
510
511 = Rebuild Debian Distribution =
512
513 The XWiki Debian distribution is automatically rebuilt every day using a crontab on ##maven.xwiki.org##.
514
515 However, in order for the Debian distribution to be ready when we announce a new version, it's a good thing to force rebuild it.
516
517 This is achieved by logging on ##maven.xwiki.org## with the ##maven## user. Then run the script.
518
519 {{code language="sh"}}
520 nohup /home/maven/xwiki_scanpackages.sh &
521 {{/code}}
522
523 This start the index update in the background, you can leave.
524
525 = Force Extensions Update =
526
527 In order to have up to date versions on https://extensions.xwiki.org you should trigger the {{velocity}}[[Batch importer scheduler>>https://extensions.xwikiorg-node1.xwikisas.com/xwiki/bin/view/Scheduler]]{{/velocity}} (from the first node of the cluster).
528
529 However before you do so, make sure to mute the IRC channel to not spam it:
530
531 {{code language="none"}}
532 /mode +q xwikibot
533 {{/code}}
534
535 And don't forget to unmute it once the release is over:
536
537 {{code language="none"}}
538 /mode -q xwikibot
539 {{/code}}
540
541 = Update Docker =
542
543 {{info}}
544 This should be done only for final versions (i.e. includes bugfixes)
545 {{/info}}
546
547 See documentation in the [[Docker GitHub project's README>>https://github.com/xwiki-contrib/docker-xwiki/blob/master/README.md#for-maintainers]].
548
549 {{info}}
550 If you need help, ask Vincent :)
551 {{/info}}
552
553 {{info}}
554 Crash course on Docker:
555
556 Docker can create Images based on a Dockerfile (or a Compose file). Docker can also download Images from the DockerHub repository. Docker can create Containers from images. Docker also creates internal Volume unless you create mapped Volumes on your host computer so that you can navigate in them as local directories.
557
558 * {{code}}docker run{{/code}} creates a container locally based on an existing docker image.
559 * {{code}}docker ps{{/code}} lists the ids of running containers
560 * {{code}}docker ps -a{{/code}} lists the ids of all containers (running or not)
561 * {{code}}docker start <id>{{/code}} starts an existing container
562 * {{code}}docker stop <id>{{/code}} stop a running container
563 * {{code}}docker rm <id>{{/code}} removes an existing container
564 * {{code}}docker volume ls{{/code}} lists existing volumes
565 * {{code}}docker volume rm{{/code}} removes an existing volume
566 * {{code}}docker system prune{{/code}} removes unused data
567 * {{code}}docker network create{{/code}} creates a docker network so that several containers can see each other
568 * {{code}}docker network ls{{/code}} lists existing docker networks
569 * {{code}}docker network rm <id>{{/code}} removes an existing docker network
570 * {{code}}docker images{{/code}} lists all local images
571 * {{code}}docker rmi <id>{{/code}} removes an existing local image
572 {{/info}}

Get Connected