Appimage and dmg are uploaded to dropbox[1]. I used the last 0.18 commit[2].

I am not sure how to handle this. We have an 0.18.16111 which is ahead of the release 0.18.16093?
It's fine for testing, but I think if I put it on github it will cause confusion.
Thanks for the AppImage, that's a nugget I wasn't expecting.

I think what he needs is the "0.19_pre" tag and update to the build system so that it would produce 0.19 versions in the about dialog and other related places. About the additional commits I would not complicate, just backport them and make a final 0.18 when ever all the things are ready. In a month or two everyone will want to be on 0.19_pre anyway

I think what he needs is the "0.19_pre" tag and update to the build system so that it would produce 0.19 versions in the about dialog and other related places. About the additional commits I would not complicate, just backport them and make a final 0.18 when ever all the things are ready. In a month or two everyone will want to be on 0.19_pre anyway

Almost.
I create the tag when I create the the release page. I needed this git commit 970af45
The small problem is that there are some "0.18" commits between the release branch and this commit, only some of which are suitable for backporting.

Most of the problem is convenience for me, as I'm set up to build from HEAD of the release branch. I want to switch to use the tags (which I can create)

So I propose to continue to work on building the binaries for 0.18 and refrain from backporting anything yet. Once this is complete, we can backport the relevant commits, create an 0.18.1 tag and release 0.18.1, hopefully using the tags as part of the build process for the binaries.

In hindsight it would be good going forward for the first commit after the release fork to activate the next dev cycle.

I don't want to come across as complaining, just an opportunity to improve going forward.

Btw.: Conda-forge freecad-feedstock will get automated PR's for everyone new tag. I now used the current 0.18 tag. I will provide the appimage and dmg for the release from local builds using the specific commit and not the tag. Once a new tag has the backports included we can also use the builds from the ci's.

I will try to work on the weekly builds to use py3.7 and the new compilers. So I am not going to create builds for tomorrow and continue with pre-0.19 on next Sunday. Hopefully we can get the weekly dmg's also ready pretty soon.

Btw.: Conda-forge freecad-feedstock will get automated PR's for everyone new tag. I now used the current 0.18 tag. I will provide the appimage and dmg for the release from local builds using the specific commit and not the tag. Once a new tag has the backports included we can also use the builds from the ci's.

You are as usual ahead of me.

Can a Mod split this topic? I highjacked the thread and wmayer's OP is important.

Appimage and dmg are uploaded to dropbox[1]. I used the last 0.18 commit[2].

@looo, can I upload these to the releases pages as release candidates (RC)?
Would you consider adding the docs only for the release?
I can probably add it to the AppImage myself if it's too much work. I think I would also need to add the QT assistant executable.
@triplus thoughts?