Fallout rebrand FAQ

[ChrisonSimtian]

Common questions about the NUKE → Fallout transition. Open a new issue if your question isn't covered.

Why the rename?

The original NUKE maintainer (@matkoch) declined to hand over maintainer status on nuke-build/nuke, so this repo is a hard fork rather than a continuation under the same name. Matt explicitly asked that the NUKE name not be carried over to the fork — hence Fallout.

The fork is heading in a slightly different direction: enterprise CI/CD focus, plugin architecture, faster decisions on breaking changes. See docs/roadmap.md for the v11/v12 plan.

Will my existing NUKE code still work?

On nuke-build/nuke: yes, indefinitely. That repo is unaffected by this fork and continues under its original maintainer.

On Fallout: yes, but you'll need to migrate. One command does it:

dotnet tool install -g Fallout.Migrate
fallout-migrate

Full walkthrough in docs/migration/from-nuke.md. If you'd rather defer, the Nuke.Common transition shim keeps your code compiling against the new types via GitHub Packages.

What about my NuGet API keys on AppVeyor / TeamCity / Octopus / ...?

Not relevant. Fallout publishes under the Fallout.* package ID prefix on nuget.org — different IDs from NUKE's Nuke.*. Your existing NuGet API key (scoped to Nuke.*) won't conflict with anything Fallout does. If you publish your own packages from a NUKE build, those keys keep working unchanged after migration.

How long will the dotnet nuke CLI keep working?

Indefinitely on nuke-build/nuke — that's the upstream global tool and not in our scope.

On Fallout, the global tool is dotnet fallout. We don't ship a dotnet nuke shim because that NuGet package ID belongs to the original NUKE maintainer. Your build.ps1 / build.sh will need to invoke dotnet fallout after migration — fallout-migrate rewrites this automatically.

Where do I file bugs?

Bugs in Fallout — open an issue here.

Bugs in the migration tooling (fallout-migrate, Fallout.Migrate.Analyzers, the shim) — also here.

Bugs in upstream NUKE that you've reproduced on nuke-build/nuke — file there: https://github.com/nuke-build/nuke/issues.

What if a bug affects both projects?

For now, file here. The two codebases share enough recent history that most bugs reproduce on both. As they diverge — and they will — you may want to file both places or pick whichever you're depending on. We won't proxy bug reports to upstream.

Can I keep using NUKE instead?

Yes, completely fine. nuke-build/nuke is the original and continues under its original maintainer. Fallout doesn't displace it. Pick whichever direction matches your needs — see the "Staying on NUKE" section of the migration guide.

Where's the documentation?

In-repo: docs/. A standalone docs site at fallout.build is planned (#41). Until that lands, the in-repo docs/ is canonical.

Will Fallout merge changes from NUKE?

Occasionally, when it makes sense. We've cherry-picked bug fixes and improvements where they fit Fallout's direction. We're not committed to staying in sync, and we'll diverge over time as v11/v12 land.

Who maintains Fallout?

Currently a small team. See README.md and costs.md for the transparency around what running the project costs.