Topic: General call for testing

I followed the link you posted above and chose the 64 bit Release build. I did not test it much though, only played the first empire scenario.

+1 for using this to provide build21-rc1 and build21 builds, but only if we can get this branch merged into master before winter time freeze. I went through the last commits in the build-20 branch and it seems like getting AppVeyor to produce the correct version involves quite some fiddling with the appveyor.yml and the innosetup script, which should be performed only once, in the build-21 branch.

Top

Quote

Nordfriese wrote:

I followed the link you posted above and chose the 64 bit Release build. I did not test it much though, only played the first empire scenario.

ok. thanks a lot for testing.

+1 for using this to provide build21-rc1 and build21 builds, but only if we can get this branch merged into master before winter time freeze. I went through the last commits in the build-20 branch and it seems like getting AppVeyor to produce the correct version involves quite some fiddling with the appveyor.yml and the innosetup script, which should be performed only once, in the build-21 branch.

Merging this is not a good idea imho. as the static build is potentially more unstable then the dynamic build as it depends on the availability of static libraries. My plan was to have this branch updated from master from time to time which will deliver a static build for all configs every time this is done. Due to the necessary changes in cmake and appveyor.yml that were necessary for this branch I really recomment to keep them separated.

Top

Quote

Nordfriese wrote:

Ah ok. So I guess we could then merge this branch into the b21 branch to get the release and RC statically linked?

yeah this might work probably, either way would be to create a rc or release brnach from the static one as well

Top

Quote