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
