Luigi is the maintainer of docs.kde.org, i'd suggest you discuss this with him. I don't see how this differs from the earlier ticket you opened with Sysadmin though where stable4/ was stated to not be available as an option.

Therefore there should be a doc branch 'stable4' for Windows and 'stable5' for non Windows and 'trunk5' for KF5 based build on Windows

As explained in the previous ticket (with links to the relevant discussions on the lists), this is not possible until master is a pure KF5 branch, using the native DTD for the baranch.

I disagree about the cost of forward-merging. That is the solution.

pure KF5 branch using the native DTD for the baranch.

kdelibs4support, which is part of KF5, provides dtd version 4.2 (see https://cgit.kde.org/kdelibs4support.git/tree/src/customization/dtd), which means that native KF5 projects using kdelibs4support could use 4.2 DTD. Umbrello/KF5 is bound to kdelibs4support, so what's the problem?

kdelibs4support is a Porting Aid, and not a native part of KF5.

The time I tried, the infrastructure didn't work. I should dig my old emails, but I'm sure I explained it by and large elsewhere.
It's a bit hacky right now, see for example this snippet:

########### install files ###############
if(BUILD_KF5)
    file(READ "index.docbook" index_file)
    string(REPLACE "4.2" "4.5" index_file "${index_file}")
    string(REPLACE "kdex.dtd" "kdedbx45.dtd" index_file "${index_file}")
    file(WRITE "index-kf5.docbook" "${index_file}")
    kdoctools_create_handbook(index-kf5.docbook INSTALL_DESTINATION ${HTML_INSTALL_DIR}/en SUBDIR umbrello)
else()

One year later, Qt 4 is gone, and kdelibs 4.x too. Please move to a pure KF5 port.

It's a bit hacky right now, see for example this snippet:

If that is all, there is no problem to switch to DTD version 4.5 and to use a workaround in the other case.

One year later, Qt 4 is gone, and kdelibs 4.x too. Please move to a pure KF5 port.

I recently tried umbrello/KF5 for Windows build on binary factory, which still contains some issues, preventing to use it as stable version:

1. On native systems it crashes without any further notice (Drkonqi and debug informations are not available to be able to get valid backtrace); dbgview showes, that it is not able to find a dbus-daemon., which looks to br

2. On a virtual box guest host it crashes too, but gives some hints:

$ umbrello5
OpenGL Warning: Assertion failed: g_pAvailableContexts[ctx->id] == ctx=0, file D:\tinderbox\add-5.1\src\VBox\GuestHost\OpenGL\state_tracker\state_init.c, line 443
OpenGL Warning: freeing context 0000000003a10080, id(0) not being in the context list
OpenGL Warning: State tracker is being re-initialized..

3. umbrello/KF5 does not have any language support

In T7659#170393, @habacker wrote:

3. umbrello/KF5 does not have any language support

Language as translations, or language as output from the classes?

The first, there is only english available

That's the build from binary factory, which is true (if I remember correctly) for all nightly snapshots. Builds from tarballs include the translations.

Luigi is correct, unless your Craft targets are setup accordingly, the system is probably building from Git.

As for the crash, you'll probably need to build Umbrello using Craftmaster locally in order to ensure all the debug symbols are available as we don't ship them with applications.

Here are a few related KF5/Windows bugs:

On native systems it crashes without any further notice
https://bugs.kde.org/show_bug.cgi?id=402289

OpenGL Warning: "Assertion failed" on virtual box windows 7 guest
https://bugs.kde.org/show_bug.cgi?id=402290

Drkonqi related open bugs on windows
https://bugs.kde.org/show_bug.cgi?id=396909
https://bugs.kde.org/show_bug.cgi?id=396893
https://bugs.kde.org/show_bug.cgi?id=396893
https://bugs.kde.org/show_bug.cgi?id=396916

In T7659#170406, @bcooksley wrote:

Luigi is correct, unless your Craft targets are setup accordingly, the system is probably building from Git.

Who can setup this ?

In T7659#170393, @habacker wrote:

It's a bit hacky right now, see for example this snippet:

If that is all, there is no problem to switch to DTD version 4.5 and to use a workaround in the other case.

fixed with https://cgit.kde.org/umbrello.git/commit/?h=Applications/18.12&id=626de6de7889b4724394cd47901fae5249ce7ec7 and merged into master

In T7659#170406, @bcooksley wrote:

As for the crash, you'll probably need to build Umbrello using Craftmaster locally in order to ensure all the debug symbols are available as we don't ship them with applications.

This is bad. Actual umbrello windows releases provides debug symbols since mid 2017 (seehttps://download.kde.org/stable/umbrello/)

In T7659#170456, @habacker wrote:

In T7659#170393, @habacker wrote:

It's a bit hacky right now, see for example this snippet:

If that is all, there is no problem to switch to DTD version 4.5 and to use a workaround in the other case.

fixed with https://cgit.kde.org/umbrello.git/commit/?h=Applications/18.12&id=626de6de7889b4724394cd47901fae5249ce7ec7 and merged into master

This is a workaround which I really don't like. Duplication is not a solution. The code readability of master is more and more complex. It would be much better to keep to separate branches.
Please revert it, or simply drop the documentation from kdelibs 4.x version on Windows. I'm not going to support it.

In T7659#170455, @habacker wrote:

In T7659#170406, @bcooksley wrote:

Luigi is correct, unless your Craft targets are setup accordingly, the system is probably building from Git.

Who can setup this ?

Patches are welcome.

For Craft itself, you need to ensure the Blueprint for Umbrello is correct first, which will be living in craft-blueprints-kde on Git.kde.org.

Once the targets are sorted out on Craft, all the Binary Factory needs to know are which targets to build for master and stable branches. This is controlled via files in sysadmin/binary-factory-tooling on Git.kde.org (craft folder)

Once those are setup, everything will work automatically. Usually only the stable release is built from tarballs, with master continuing to come from Git.

As for why debug symbols aren't shipped alongside, that is because the Installers generated by the Binary Factory are meant for final end users to use, and making debug symbols available separately hasn't been a priority for now.

In T7659#170480, @bcooksley wrote:

Patches are welcome.

where to send patch - to a phabricator task or posting a code review ?

For Craft itself, you need to ensure the Blueprint for Umbrello is correct first, which will be living in craft-blueprints-kde on Git.kde.org.

see T10197

Once the targets are sorted out on Craft, all the Binary Factory needs to know are which targets to build for master and stable branches. This is controlled via files in sysadmin/binary-factory-tooling on Git.kde.org (craft folder)

I will take a look

Once those are setup, everything will work automatically. Usually only the stable release is built from tarballs, with master continuing to come from Git.

Thanks for this info

As for why debug symbols aren't shipped alongside, that is because the Installers generated by the Binary Factory are meant for final end users to use, and making debug symbols available separately hasn't been a priority for now.

KDE applications normally uses drkonqi for generating useful bug reports, which installs debug packages by itself (at least on linux os) for generating backtraces. As mentioned in T7659#170454 drkonqi is broken on Windows, but after the issues will be fixed, debug symbols will be recommended.

Patches should be posted as a Phabricator review.