It’d be nice if we could beta test new features (such as the new zstd compression method, new Samba backend), without having to go through the whole process of compiling the go code ourselves.
Most importantly - for those that report a specific bug and it gets fixed for them - they can use that fix and test it quickly.
Could github action workflows be used here to auto build nightly binaries for every platform?
I agree, it will be nice.
Sorry to bump this topic, maybe I should’ve pinged @gchen from the start? 
When can we expect a new CLI release, so we can start using zstd and Samba etc.?
In future, can we get pre-release nightly builds?
Can we have up-to-date, official build instructions for all platforms? Or more specifically, could you provide details on how you put out release binaries?
I notice this guide page on the forum is slightly different from the one on the GitHub wiki (an example is the CLI build link is missing). Perhaps the former should be deprecated and link to the wiki/docs instead?
On the topic of docs, what’s the latest on the plan to create a separate docs.duplicacy.com site using MkDocs?
I briefly looked into this, and it appears github wiki’s are basically a git repository under the hood, and can be cloned by replacing .git with .wiki, like so:
git clone https://github.com/gilbertchen/duplicacy.wiki
If I may suggestion creating a separate new duplicacy-docs repo and keep it in standard markdown. MkDocs can deploy on GitHub Pages with GitHub Actions, or can build and hosted elsewhere.
I understand you may want to integrate documentation for the Web UI along with the CLI, but since the former doesn’t have a great deal on that anyway, having a separate site available for both would be very useful starting point.
I’ll make a new one in a few days.
I’ll look into this.
Those instructions need to be updated since we’re now using go modules. For now, the easiest way is as follows:
git clone http://github.com/gilbertchen/duplicacy
go build duplicacy/duplicacy_main.go
I don’t think a separate doc site is necessary. I would stick with the wiki page.
Awesome!
Thanks, although I was mainly enquiring about how you go about building binaries for all the platforms.
One of the things that got me wondering is to the feasibility of using a docker build container to spit out cross-platform releases with very minimal effort.
Indeed, although forked builds (like for testing features such as a mount cmd) is still a bit messy.
That’s disappointing to hear.
The problem with how it’s presented on the github wiki atm, is you don’t have an (organised) ever-present Table of Contents, so it’s hard to find stuff if you don’t know what you’re looking for. MkDocs makes it super easy to search (just press s) and could easily be hosted even on GitHub Pages with just a little effort.
Perhaps I’ll fork and knock up a quick demo site…
In the early days of this forum there was talk about where the user guide should be hosted, here or on the github wiki, and then the “guide” above was created here.
To my surprise, some time ago the guide “was moved” to the github wiki, I imagine gchen has its reasons for keeping it along with the code.
From my experience (in other projects) the knowledge about a certain service/product must be in a single place. Hint: tacit knowledge (from user experience) is here on the forum. 
I build all binaries on macOS. For all other platforms I can cross-build for them but macOS binaries have to be treated differently – they need to be code-signed and notarized.
The build command is a simple line for each platform, like:
env GOOS=darwin GOARCH=arm64 go build -ldflags "-X main.GitCommit=$commit" -a -o releases/$version/duplicacy_osx_arm64_$version duplicacy/duplicacy_main.go