Difference between revisions of "PIM/Akonadi/Release Howto"

< PIM‎ | Akonadi
Jump to: navigation, search
(Step 3: Tarball Creation)
m (38 revisions imported)
 
(19 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
How to do a release of the Akonadi server? I ask that myself and then Tom every time I have to do it. So, finally document that here.
 
How to do a release of the Akonadi server? I ask that myself and then Tom every time I have to do it. So, finally document that here.
  
== Step 1: Changelog, NEWS, version number ==
+
== Step 0: Make sure all unit tests pass ==
  
Run the ''makechangelog'' script in the source directory (which either is trunk or ''branches/akonadi/<version>'' depending on if you are doing a major (pre-)release or a minor one):
+
Run make test every time before committing and especially before making a release to avoid the embarassing emails from Jenkins. Seriously, how hard is it to remember this?
  
<code bash>
+
== Step 1: Changelog, NEWS, version number ==
sh makechangelog
 
</code>
 
 
 
That will add all revisions since the last time to the ''ChangeLog'' file.
 
 
 
 
 
Next step is to update the NEWS file, run ''svn diff ChangeLog'' and summarize the changes for that.
 
  
 +
First, update the NEWS file. It should contain a high-level summary of the changes since the last release.
 +
To obtain the full log of all changes since the last release, run the following command or have a look in ''gitk'':
  
Finally, update the version number in the top-level CMakeLists.txt and commit all your changes.
+
<syntaxhighlight lang="bash">
 +
git log vx.y.(z-1)..
 +
</syntaxhighlight>
  
 +
Finally, update the version number in the top-level CMakeLists.txt and Mainpage.dox and commit/push all your changes.
  
 
== Step 2: Tagging/Branching ==
 
== Step 2: Tagging/Branching ==
  
Tagging a major (pre-)release, i.e. a release from trunk is done with the following (server side and thus fast) ''svn'' command:
+
Tagging a major (pre-)release, i.e. a release from master is done with the following commands:
 
 
<code bash>
 
svn cp $SVNPROTOCOL://[email protected]/home/kde/trunk/kdesupport/akonadi $SVNPROTOCOL://[email protected]/home/kde/tags/akonadi/x.y.z
 
</code>
 
 
 
Obviously, replace protocol, username and version with appropriate values.
 
  
 +
<syntaxhighlight lang="bash">
 +
git checkout master
 +
git tag -a vx.y.z -m "Akonadi x.y.z"
 +
git push
 +
git push --tags
 +
</syntaxhighlight>
  
 
For a stable release, that is a release from a stable branch, the command looks like this:
 
For a stable release, that is a release from a stable branch, the command looks like this:
  
<code bash>
+
<syntaxhighlight lang="bash">
svn cp $SVNPROTOCOL://[email protected]/home/kde/branches/akonadi/x.y $SVNPROTOCOL://[email protected]/home/kde/tags/akonadi/x.y.z
+
git checkout x.y
</code>
+
git tag -a vx.y.z -m "Akonadi x.y.z"
 
+
git push
 
+
git push --tags
=== Update the kdesupport-for-4.x tag ===
+
</syntaxhighlight>
 
 
It might also be needed to update the latest kdesupport-for-4.x tag with the new release. Use the following commands for that:
 
 
 
<code bash>
 
svn rm $SVNPROTOCOL://[email protected]/home/kde/tags/kdesupport-for-4.x/akonadi
 
svn cp $SVNPROTOCOL://[email protected]/home/kde/tags/akonadi/x.y.z $SVNPROTOCOL://[email protected]/home/kde/tags/kdesupport-for-4.x/akonadi
 
</code>
 
  
 
=== Creating a new stable branch ===
 
=== Creating a new stable branch ===
Line 49: Line 40:
 
A new stable branch is created by the following command:
 
A new stable branch is created by the following command:
  
<code bash>
+
<syntaxhighlight lang="bash">
svn cp $SVNPROTOCOL://[email protected].kde.org/home/kde/trunk/kdesupport/akonadi $SVNPROTOCOL://[email protected]/home/kde/branches/akonadi/x.y
+
git checkout -b x.y
</code>
+
# do modifications as described above
 +
git push origin x.y
 +
</syntaxhighlight>
  
 
Afterwards perform the following steps:
 
Afterwards perform the following steps:
* increment the version number in trunk
+
* increment the version number in master
* adapt the SVN url in the makechangelog script in the new branch
 
  
== Step 3: Tarball Creation ==
+
== Step 2.5: Get translations ==
  
You need the tarball creation script from ''kdesdk'' for that.
+
Ping Albert, he will show you how to do it. Then update this guide so that we don't have to ping him again.
  
<code bash>
+
== Step 3: Tarball Creation ==
cd KDE/kdesdk/scripts/createtarball
 
</code>
 
  
 +
Run the following command to create the tarball:
  
Next, edit ''config.ini'' to contain the following for releases from trunk:
+
<syntaxhighlight lang="bash">
 +
git archive --format=tar --prefix=akonadi-x.y.z/ vx.y.z | bzip2 -9  > akonadi-x.y.z.tar.bz2
 +
</syntaxhighlight>
  
<code ini>
+
== Step 4: Upload ==
[akonadi]
 
mainmodule  = trunk/kdesupport
 
submodule  = akonadi
 
wholeModule = yes
 
version    = x.y.z
 
docs        = no
 
translations= no
 
remove      = makechangelog
 
</code>
 
 
 
For releases from the branch, ''config.ini'' needs to contain the following:
 
 
 
<code ini>
 
[akonadi]
 
mainmodule  = branches/akonadi
 
submodule  = x.y
 
wholeModule = yes
 
version    = x.y.z
 
docs        = no
 
translations= no
 
remove      = makechangelog
 
</code>
 
  
Then, run the ''create_tarball'' script:
+
Upload the tarball to ftp://upload.kde.org/incoming/, using e.g. the following command:
  
<code bash>
+
<syntaxhighlight lang="bash">
./create_tarball.rb -u $SVNUSER -a akonadi
+
ftp -u ftp://upload.kde.org/incoming/ akonadi-x.y.z.tar.bz2
</code>
+
</syntaxhighlight>
  
Add a ''-w'' there if you are using https instead of ssh to access subversion.
+
Afterward, create a KDE Sysadmin ticket at https://sysadmin.kde.org/tickets/ (department "download.kde.org") and fill in the following information in the form:
 
+
* Name of the tarball: akonadi-x.y.z.tar.bz2
Wait a bit and check the tarball created in the current directory. Should be ''akonadi-x.y.z.tar.bz2''.
+
* SHA-256 sums for the tarball
 
+
* Intended destination is stable/akonadi/src/.
TODO: can we simplify this by e.g. using CPack?
 
 
 
== Step 4: Upload ==
 
  
Upload the tarball somewhere and notify Tom or Volker to move it to http://download.akonadi-project.org/ (unless you are one of those two, then upload directly).
+
Wait for the request to be processed (you'll get an email notification) and the mirrors to propagate the new file (~2h).
  
 
== Step 5: Bugzilla ==
 
== Step 5: Bugzilla ==
Line 118: Line 86:
 
TODO
 
TODO
  
== Step 7: Dirk ==
+
== Step 7: <s>Dirk</s>Albert ==
  
Finally, apologize to Dirk for being late again with the release ;-)
+
Finally, apologize to <s>Dirk</s>Albert for being late again with the release ;-)
  
 
[[Category:Akonadi]] [[Category:PIM]]
 
[[Category:Akonadi]] [[Category:PIM]]

Latest revision as of 13:01, 11 March 2016

How to do a release of the Akonadi server? I ask that myself and then Tom every time I have to do it. So, finally document that here.

Step 0: Make sure all unit tests pass

Run make test every time before committing and especially before making a release to avoid the embarassing emails from Jenkins. Seriously, how hard is it to remember this?

Step 1: Changelog, NEWS, version number

First, update the NEWS file. It should contain a high-level summary of the changes since the last release. To obtain the full log of all changes since the last release, run the following command or have a look in gitk:

git log vx.y.(z-1)..

Finally, update the version number in the top-level CMakeLists.txt and Mainpage.dox and commit/push all your changes.

Step 2: Tagging/Branching

Tagging a major (pre-)release, i.e. a release from master is done with the following commands:

git checkout master
git tag -a vx.y.z -m "Akonadi x.y.z"
git push
git push --tags

For a stable release, that is a release from a stable branch, the command looks like this:

git checkout x.y
git tag -a vx.y.z -m "Akonadi x.y.z"
git push
git push --tags

Creating a new stable branch

A new stable branch is created by the following command:

git checkout -b x.y
# do modifications as described above
git push origin x.y

Afterwards perform the following steps:

  • increment the version number in master

Step 2.5: Get translations

Ping Albert, he will show you how to do it. Then update this guide so that we don't have to ping him again.

Step 3: Tarball Creation

Run the following command to create the tarball:

git archive --format=tar --prefix=akonadi-x.y.z/ vx.y.z | bzip2 -9  > akonadi-x.y.z.tar.bz2

Step 4: Upload

Upload the tarball to ftp://upload.kde.org/incoming/, using e.g. the following command:

ftp -u ftp://upload.kde.org/incoming/ akonadi-x.y.z.tar.bz2

Afterward, create a KDE Sysadmin ticket at https://sysadmin.kde.org/tickets/ (department "download.kde.org") and fill in the following information in the form:

  • Name of the tarball: akonadi-x.y.z.tar.bz2
  • SHA-256 sums for the tarball
  • Intended destination is stable/akonadi/src/.

Wait for the request to be processed (you'll get an email notification) and the mirrors to propagate the new file (~2h).

Step 5: Bugzilla

Log into http://bugs.kde.org/, chose Edit Products -> Akonadi -> Add version and add the version you just released.

Step 6: Announcements

Update channel topic on #akonadi.

TODO

Step 7: DirkAlbert

Finally, apologize to DirkAlbert for being late again with the release ;-)


This page was last edited on 11 March 2016, at 13:01. Content is available under Creative Commons License SA 4.0 unless otherwise noted.