Elmish.wpf: Remove Paket and FAKE and simplify release?

[cmeeren]

Originally commented in https://github.com/elmish/Elmish.WPF/issues/106#issuecomment-535350442

Paket and FAKE

Paket and FAKE are additional tools in the toolchain that may not be needed. I'm usually in favour of using the simplest tooling that gets the job adequately done. I'm not convinced Paket or FAKE adds much to Elmish.WPF development/maintenance, particularly since everyone using WPF is likely to be using Visual Studio anyway and since the built script is trivial. In fact, I think that using just NuGet and VS (or plain dotnet CLI if needed) may be simpler for contributors than using FAKE and Paket (see e.g. https://github.com/elmish/Elmish.WPF/issues/106#issuecomment-535339702). Therefore I am considering removing all Paket and FAKE stuff and just use NuGet references in the project files.

Releases and stable-* brances vs. master

I'm also considering removing the stable-* branches and just triggering releases from master using tags. I have never used the stable-* branches to release anything on an old major version, and I can't imagine doing it in the foreseeable future. If it is ever needed, we can just branch out from the latest release commit for a certain major release and backport fixes to that.

---

Check out the remove-paket-fake branch to see how I envision it to be after simplifying it.

[TysonMN]

Re: branches and tags. I like that idea. Among automated build and release solutions that I have seen, I am most impressed when a build happens automatically when code is pushed to a certain branch and a release happens when certain a tag is pushed to one of those branches. I have setup several automated build and release solutions before, but I have never done releases when a tag is pushed. It is on my list of things to eventually figure out.

[TysonMN]

Re: Paket and FAKE. I always use Visual Studio. I have never used Paket or FAKE. I had never heard of Paket before I started using Elmish.WPF (probably because I started primarily coding in F# around the same time).

FAKE seem like a good idea in general: a build system configured by files committed in the repository and locally executable by every developer. I like this in theory, but I haven't felt like I needed it in practice. In practice, building and running all tests is easily done through Visual Studio (hotkeys Ctrl+Shift+B and Ctrl+R, A respectively, which I have bound to gammer keys G6 and G5 respectively), and NuGet packages are configured to restore automatically. In my experience, the differences between development environments among my coworkers and our clients is rare and small. I can see how FAKE would be much more useful in the F# OSS community where not everyone uses Visual Studio and, even if they do, there could be many differences among development environments.

My current project at work is hosted on Azure DevOps, and we configure the builds that are run on the build server using YAML files committed into the repository. The only annoying thing with this approach is that it is (currently) difficult to test changes to the YAML files.

Testing currently involves manually queueing a build in Azure DevOps and seeing if it fails. If it does fail, then you only have the log files to diagnose the problem instead of also having all of the files created during the build. This leads to more iterations to get it right, each of which is rather long.

One workaround is to install an agent on your local system and add that agent to your agent pool on Azure DevOps. Then you can queue builds that use this agent. I haven't done this myself, but I know others that have.

The "correct fix", which is in the works by Microsoft, is to support local execution of the YAML-specified builds. I haven't tried this yet either, but I expect I will start using it once it is released. It will be welcome addition to the process of modifying the YAML files and marginally more useful as a source-of-truth developer-local build.

[cmeeren]

If CI configs (whether Azure Pipelines or otherwise) are often giving you trouble, FAKE might be a good solution, because the CI config can be almost trivial (fake build) and you can test everything locally. But personally I'd have to endure quite a bit of CI troubles before using FAKE just for that reason.

Also FAKE is great if you need more complex or custom build steps. For example, in one of my projects I need a step to generate some code based on files in some restored npm packages, and that fit well in a FAKE script.

In any case, it seems we agree. :) I'll leave this open for a few days to see if others want to weigh in, and maybe merge #129 during the weekend if I don't hear any complaints.

[ChrisPritchard]

Yes please, do this. Fake and Paket seem to get added as a sort of cargo-cult/language loyalty with F# OSS projects, but they always seem to cause nothing but issues when I clone something down. Issues to which the fix is simply to delete all references to Paket and Fake, which nine times out of ten results in successful builds.

Especially with dotnet core and its lighter/more reliable MSBuild and Nuget, I just don't see the point unless you have a really complicated build pipeline, which is probably a problem that should be addressed on its own.

[cmeeren]

Thanks for your opinion, @ChrisPritchard!

They always seem to cause nothing but issues when I clone something down. Issues to which the fix is simply to delete all references to Paket and Fake, which nine times out of ten results in successful builds.

Yes, that is often my experience, too.

---

Since I'm hearing only support and no complaints, I will merge #129 soon, maybe later today.

[ChrisPritchard]

Very nice, very clean!