Prepare release, get to know the scripts.
[x] Decide on a release date
* 2016-09-19
[x] Decide on a string freeze time frame before the release. This freeze should be upwards of 7 days before a release. For most medium sized projects a freeze of 14 days is recommendable.
* 2016-09-13
[x] When string freeze draws closer make sure the correct branches are set for i18n trunk or i18n stable (depending on what you want to release). If you change the settings also make sure to inform the translators of the move either on IRC or by mail at kde-i18n-doc@kde.org
[x] Inform the translation teams kde-i18n-doc@kde.org when you start string freeze and tell them when the release is due so they can plan accordingly.
[x] On release day run tarme with the correct origin and version
[x] Verify the tarball and do a test build, possibly ask peers to build on their systems as well.
[x] Upload to ftp://depot.kde.org/ and note the README in there.
[x] File a ticket with the sysadmins to move your tarball into a suitable place on http://download.kde.org. If you are unsure about where to put it you can ask the release-team@kde.org for some guidance.
[ ] Push tags (or run tagme to tag your release in git)
[x] Once the sysadmins have processed your ticket announce the release in whatever way that seems reasonable (blog post, dot.kde.org, kde-announce-apps@kde.org, twitter, facebook, g+ etc. etc. etc.)
------
Some chat about what's available:
```
<jstaniek> hi, looking for a volunteer who would manage release scripts for repos (kexi, kdb,
kproperty, kreport), there are no scripts no tarballs with source/translations; until there's a
workforce releases would only happen on GIT
<tosky> jstaniek: just to understand, do you want to write another set of release script?
<jstaniek> tosky: I'd like to outsource 99% of that :)
<jstaniek> especially i18n
<jstaniek> are release scripts created by forking some existing ones? (these days)
<tosky> kde-dev-scripts, createtarball/create_tarball_kf5.rb
<jstaniek> yep.. kf5 scripts look as the closest fit
<boud> jstaniek: that one worked out of the box for krita
<jstaniek> very good
<jstaniek> -- trying to push the betas out close to Akademy
<Riddell> jstaniek: kde:releaseme is your friend
<Riddell> jstaniek: one simple command to make all your tars
<tosky> Riddell: I think it has some issues with translated documentation
<Riddell> always works for me
<tosky> Riddell: can you check the last changes in create_tarball_kf5? It was changed to
properly use ki18n_install and kdoctools_install, maybe you can apply them to releaseme
<tosky> Riddell: it didn't work, I think I told you some time ago, translation of khelpcenter
documentation was not properly placed when khelpcenter was part of Plasma
<tosky> boud: ehm, about that, at leat in the last krita-3.0.99.91.tar.gz one of the po is
missing (kritacrashhandler.po), I think you may want to add it to the config.ini file for
create_tarball_kf5
<jstaniek> honestly I was trying to find official recommendation docs and found mostly
https://community.kde.org/Policies/Application_Lifecycle
https://community.kde.org/Release_Team/Release_Process
<jstaniek> I know many projects have own scripts and I'd like to avoid this
<Riddell> jstaniek: I don't think there are any official recommended ways to do it, as
plasma release dude I recommend releaseme
<jstaniek> Riddell: very good, thanks; as there is 2 weeks of time recommended for the
release process I think I'd be announcing availability of a preview version on GIT, blogging,
get opinions and try the scripts
<Riddell> jstaniek: for plasma I make beta tars 2 weeks before which is a test incase the
tars are broken in some way or I've missed something out, that's also the time I make the
stable branches (which is also done by releaseme)
```