PIM/Akonadi/Release Howto: Difference between revisions

From KDE Community Wiki
< PIM‎ | Akonadi
m (38 revisions imported)
 
(33 intermediate revisions by 4 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 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 ==
== Step 1: Changelog, NEWS, version number ==


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):
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'':


<code bash>
<syntaxhighlight lang="bash">
sh makechangelog
git log vx.y.(z-1)..
</code>
</syntaxhighlight>


That will add all revisions since the last time to the ''ChangeLog'' file.
Finally, update the version number in the top-level CMakeLists.txt and Mainpage.dox and commit/push all your changes.


== Step 2: Tagging/Branching ==


Next step is to update the NEWS file, run ''svn diff ChangeLog'' and summarize the changes for that.
Tagging a major (pre-)release, i.e. a release from master is done with the following commands:


<syntaxhighlight lang="bash">
git checkout master
git tag -a vx.y.z -m "Akonadi x.y.z"
git push
git push --tags
</syntaxhighlight>


Finally, update the version number in the top-level CMakeLists.txt and commit all your changes.
For a stable release, that is a release from a stable branch, the command looks like this:


<syntaxhighlight lang="bash">
git checkout x.y
git tag -a vx.y.z -m "Akonadi x.y.z"
git push
git push --tags
</syntaxhighlight>


== Step 2: Tagging/Branching ==
=== Creating a new stable branch ===


Tagging a major (pre-)release, i.e. a release from trunk is done with the following (server side and thus fast) ''svn'' command:
A new stable branch is created by the following command:


<code bash>
<syntaxhighlight lang="bash">
svn cp $SVNPROTOCOL://$SVNUSER@svn.kde.org/home/kde/trunk/kdesupport/akonadi $SVNPROTOCOL://[email protected]/home/kde/tags/akonadi/x.y.z
git checkout -b x.y
</code>
# do modifications as described above
git push origin x.y
</syntaxhighlight>


Obviously, replace protocol, username and version with appropriate values.
Afterwards perform the following steps:
* increment the version number in master


== Step 2.5: Get translations ==


For a stable release, that is a release from a stable branch, the command looks like this:
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 ==
svn cp $SVNPROTOCOL://[email protected]/home/kde/branches/akonadi/x.y $SVNPROTOCOL://[email protected]/home/kde/tags/akonadi/x.y.z
</code>


=== Creating a new stable branch ===
Run the following command to create the tarball:


A new stable branch is created by the following command:
<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 bash>
== Step 4: Upload ==
svn cp $SVNPROTOCOL://[email protected]/home/kde/kdesupport/akonadi $SVNPROTOCOL://[email protected]/home/kde/branches/akonadi/x.y
</code>


== Step 3: Tarball Creation ==
Upload the tarball to ftp://upload.kde.org/incoming/, using e.g. the following command:


You need the tarball creation script from ''kdesdk'' for that.
<syntaxhighlight lang="bash">
ftp -u ftp://upload.kde.org/incoming/ akonadi-x.y.z.tar.bz2
</syntaxhighlight>


<code bash>
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:
cd KDE/kdesdk/scripts/createtarball
* Name of the tarball: akonadi-x.y.z.tar.bz2
</code>
* SHA-256 sums for the tarball
* Intended destination is stable/akonadi/src/.


Edit ''config.ini'' to use the right version, in the ''[akonadi]'' section. Then, run the ''create_tarball'' script:
Wait for the request to be processed (you'll get an email notification) and the mirrors to propagate the new file (~2h).


<code bash>
== Step 5: Bugzilla ==
./create_tarball.rb -u $SVNUSER -a akonadi
</code>


Add a ''-w'' there if you are using https instead of ssh to access subversion.
Log into http://bugs.kde.org/, chose ''Edit Products -> Akonadi -> Add version'' and add the version you just released.


Wait a bit and check the tarball created in the current directory. Should be ''akonadi-x.y.z.tar.bz2''.
== Step 6: Announcements ==


== Step 4: Upload ==
Update channel topic on #akonadi.


Upload the tarball somewhere and notify Tom to move it to http://download.akonadi-project.org/.
TODO


Finally, apologize to Dirk for being late again with the release ;-)
== Step 7: <s>Dirk</s>Albert ==


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 ;-)