Disabled DevBuild Setting

[martindevans]

Disabled DevBuild, this downloads a potentially incompatible version of wasmtime and should not be enabled by default! This setting was causing CI to fail.

There were three settings for this:

• Directory.Build.props
• CI env hardcoded to false
• CI conditionally overwriting this to true

I have set the props file to false and removed both of the CI options.

[martindevans]

Well that didn't work!

[martindevans]

macos has no errors in the log, it looks like it might just be a transient error.

[jsturtevant]

While I generally agree with this. This has a little history on releases.

#315 (comment)

So there might be some ci stuff we need to deal with down the line.

[martindevans]

From that discussion it looks like the main issue it's trying to solve is when wasmtime has devbuild changes and wasmtime-dotnet is patched to support those changes. If we merge those changes to master we need some way to tell the CI to pull the devbuild version.

That seems like a risky thing to ever do though! It leaves master in a state that might randomly break at any moment (when new upstream dev binaries are built) and cannot be reproduced in the future (since we don't record exactly which version it was built against).

How about having a policy of master always being built against a specific wasmtime release version. If we want to develop against bleeding edge devbuilds that can be done with PRs into a dev branch (with devbuild=true), that branch is only merged into master when devbuild=false and WasmtimeVersion is updated.

[jsturtevant]

Agree with your analysis, I think it will be easier for new comers to understand this. It is also just as easy wait for a wasmtime release and submit a single pr moving the branch forward to the last released version. I think it made sense for the previous maintainers since they were extremely active in both projects.