Well I am not pushing for the cert, in fact it's hard to say how it would be seen by users: is KEXI widely certified and tested by KDE? No, no KDE app is, it's local work.
Maybe I'll have commercial certification or/and the app in app stores. Too early to say.
Thanks.

BTW is it possible to get KDE certificate for the installer?

• KEXI: qtlocation and qtsensors are needed by Qt5WebKit, do not disable

• KEXI: Use "explorer <link>" to Run KEXI per user request, under explorer's user

• KEXI: move files copying to preArchive()

• KEXI: Update package names, ignore also: kemoticons, kdesignerplugin, hunspell-dictionaries

In D19740#438483, @vonreth wrote:

@vonreth Everything works as I expected now...

• KEXI installer - vcredist: we don't ship the installer anymore but the dlls directly
• KEXI: Improve blacklist and whitelist
• KEXI: make custom nullsoftinstaller.nsi closer to the Craft's official, port kexi.py to it
• KEXI: ignore hunspell and qtlocation/sensors/qqcontrols2
• Simplify blacklist for KEXI, ignore more files
• NSIS Installer for KEXI: Improve start menu and install dir removal (remove parent KEXI folder if makse sense), fix folder names

Updated files, now the installer builds and works. "Run KEXI" from installer does not work and start menu location is not as I expected.

Thanks @bcooksley and @apol

Very good, by chance, where are the artifacts for kexi builds?

Thanks a lot @apol, it looks promising and clean. I have questions based on my limited knowledge of these json files:

• kreport, kproperty, kdb modules - can their branch be 3.2 too? They're BC but still using stable dependencies for stable builds would be better
• the top level "branch" attribute is master, not sure what it means
• what would be the URL at https://binary-factory.kde.org/ for the stable?

Right, for master and stable (currently "3.2").

@apol Thanks, adding another nightly for other branch was my initial though. Can we add this? We would be done then.

Thanks Ben, it's hard to argue with this standard behavior. I am wondering though how to trigger the build in projects like KEXI - there can be weeks of development when changes are in kdb.git only and not in kexi.git. More precisely, how to deal with that without adding artificial commits to kexi.git.

Landed, now how to rebuild it? Can I get rights to click Rebuild?
I may want this in other cases, e.g. when kexi.git is unchanges but when dependencies changed and we want to test things while testers are waiting for binaries. For nightly builds it means one test per 24h I'd assume?

Yes, Ben summarized what I meant. Thanks. We're not yet there (that is, production-ready flatpack or app store of any kind, with QA and regular contributors). We can't have all of this the day one, we need nighties so would-be contributors who are not developers have the chances to test current software (stable/unstable). Current state is that many contributors (power users) run 1 or 2 years old software so even initial conversation within bugs.kde.org is problematic.

In T10377#174777, @apol wrote:

In T10377#174613, @staniek wrote:

Thanks Aleix. I'd like to understand: you are not planning it but do you see some rejection by principle or by technical reason?

I'd say it's not very practical. But we could do it if necessary.

Bottom line is that for Windows there is no such split and stable software "by KDE" has chance to be shipped.

I'd say going all the way on Windows stable releases would mean to get the application on the Windows Store. It should be the maintainer who does that.

Thanks Aleix. I'd like to understand: you are not planning it but do you see some rejection by principle or by technical reason?
Bottom line is that for Windows there is no such split and stable software "by KDE" has chance to be shipped.

@apol Hi Aleix, is there any support for stable builds?

Thanks for the hint.

@piggz
Pushed for 3.2 Beta, post-commit review would be welcome.

Planned for 3.2.0 after Beta.

@piggz
Pushed for 3.2 Beta, post-commit review would be welcome.