Release, again

[Friedrich W. H. Kossebau]

Hi Dag,

Am Freitag, 25. November 2016, 12:14:05 CET schrieb Dag:
> Hi, everybody
> We are closing in on release I don't think I know of more than getting
> the migration stuff in.
> Has anybody anything else they think has to be done before release?
> 
> Boudewijn, is there anything we need to prepare before we (you) start
> creating tarballs.
> I had a look at the release script and couldn't find anything about
> calligra in the config file.

For a start you might perhaps also try the "old" Calligra-specific scripts 
from Cyrille. See them linked in section "Tarball creation" of https://
community.kde.org/Calligra/Release_Howto

> Also we are not releasing all apps, how do we handle that?

There is a check in the toplevel CMakeLists.txt which will disable all 
products tagged with STAGING in release build mode (near l.141). That's also 
how it was done in the last 2.9 releases.
So the source tarball would as before contain the complete snapshot of the 
repo, dumping things is then done at build time.

> What about translations? I have a couple of new strings in plan, but I
> wouldn't loose much sleep if they were not translated for 3.0.

Translators prefer to be notified about upcoming release (which also means 
frozen strings then) at least one week or better more. So if you schedule the 
tarball creation for, say, December 4th and tell them immediately, that might 
give them the change to brush over the strings catalogs a little (best also 
tell which catalogs belong to staging products so do not need attention 
currently).

> Then after release, do we work in master AND the 3.0 branch or should we
> maybe just work on master.
> If we restrict to bug fixes we could maybe just use master? What do you
> think?

Given the amount of developer power currently a separate 3.0 branch would need 
too much attention which nobody might have while working on master. So perhaps 
having master as continous release branch where both bug fixes and new 
features (but only completed ones) are committed would be the best for now to 
ensure quality in what is released. As this way all developers see the branch 
and their issues most of the time (when not in a personal feature branch).

Cheers
Friedrich