Skip to content

roadmap.md

Latest commit

 

History

History
89 lines (55 loc) · 8.88 KB

roadmap.md

File metadata and controls

89 lines (55 loc) · 8.88 KB
Raw

Fallout roadmap

This document explains where Fallout is going and why. It's the canonical reference for the next two themed milestones. If you want to influence the direction, the RFCs linked below are open for comment now.

Versioning note. Fallout ships classic semver (ADR-0009), which replaces the short-lived calendar-versioning experiment in ADR-0004. Versions stay on 10.x — 10.4, 10.5, 10.6, and so on — until a breaking change is actually needed. v11 is deferred as long as possible, not scheduled. The work below ships as originally planned: the rebrand + plugin-foundation milestone as ordinary non-breaking 10.x releases, and the public plugin SDK whenever v11 eventually happens. Milestones are theme-based and carry across releases — they aren't tied to a specific version number.

Where we are

Fallout is the hard-fork successor to NUKE. The rebrand from NUKE to Fallout is in flight — most of the renaming has landed; consumer-facing migration tooling, the documentation site port, and the coordinated announcement are still in progress. Active development ships as non-breaking 10.x releases (develop → preview is the sole prerelease lane, production = main via a release/vX.Y stabilization branch); the older support/v10 line covers versions before 10.4 (security/critical fixes only).

The next two themed milestones

Rebrand completion + plugin-architecture foundation (current 10.x line)

Milestone: Plugin architecture foundation & rebrand completion

This milestone finishes the rebrand and lays the internal groundwork for a plugin model. It bundles two workstreams so consumers face a single migration wave instead of two:

Workstream A — Rebrand completion. Ship the Nuke.* → Fallout.* transition shims with full public-API coverage, the migration CLI (Fallout.Migrate), the Roslyn codefix for using directives, the migration guide, the documentation site port, and the coordinated announcement.

Workstream B — Plugin-architecture foundation (internal). Restructure the build orchestrator so a plugin SDK can sit on top later:

  • Extract a Fallout.Core domain project — pure, immutable, dependency-free.
  • Introduce dependency injection inside the orchestrator (consumer-facing Execute<T>() stays unchanged).
  • Wrap IO, process, and console statics behind injectable interfaces (statics on the surface, DI underneath).
  • Split the FalloutBuild god class into its three distinct responsibilities.
  • Replace the 23 init-pipeline attributes with an internal IBuildMiddleware pipeline.
  • Add architectural-fitness tests so the new layers stay clean.
  • Lift orchestration-path test coverage to ~80%.

What this milestone is not: it ships no public plugin SDK. The internal interfaces (IBuildMiddleware, ITargetLifecycleListener, infrastructure interfaces) stay internal. Their shape needs to bake through dogfooding before becoming part of a public contract — see the SDK milestone below.

The full ticket list is in milestone #6. Workstream A is the release-blocker; Workstream B slips to a later 10.x minor if it threatens the rebrand completion.

Public plugin SDK (v11, whenever that happens)

Milestone: Public plugin SDK

This milestone commits the public contract that third-party contributors compile their plugins against. After the foundation has been dogfooded, the shapes that prove themselves become public, additive-only API in Fallout.Plugin.Sdk 1.0:

  • A plugin will be a NuGet package + a single [assembly: FalloutPlugin(typeof(...))] attribute + an IFalloutPlugin.Configure(builder) method. Same convention as Roslyn analyzers, MSBuild SDKs, source generators.
  • The SDK exposes a closed catalogue of extension points (build middleware, CI host adapters, parameter sources, tool-wrapper contributions, lifecycle listeners, output sinks).
  • The SDK versions independently of the Fallout host. Strict additive-only minors; breaking changes only in majors (batched to the next major cut); major bumps are rare.
  • First-party CI host adapters migrate to the SDK as dogfood proof.
  • A canonical sample plugin + plugin author's guide ship with the SDK.

The exact shape isn't pinned yet — that's what the RFCs are for.

Beyond the plugin SDK — Continuous Delivery vision

Milestone: Continuous Delivery vision

Long-horizon direction: extend Fallout beyond CI into release management and deployment orchestration — the space currently owned by TeamCity, Octopus Deploy, and the release stages of Azure DevOps Pipelines. The wedge hypothesis is the same one that powers Fallout-on-CI: C#-native, code-first, single binary, leveraging the plugin SDK.

Shape is genuinely TBD. The milestone collects RFCs and scoping work; no release-date commitment. Comment on #106 with deployment shapes you'd want to use Fallout for.

How to engage — RFCs open now

Five RFC issues are open to shape the public plugin SDK. These are self-RFCs: each one ships an opinionated proposal and asks "tell me where I'm wrong" rather than "what should we do." Strong opinions backed by use cases are the most useful kind of comment.

Comment by 2026-08-31. After that date, each proposed shape locks, rolls into the implementing SDK-* issue named on the RFC, and the RFC closes as decided. The proposals are the working baseline; silence means assent.

The most useful contribution you can make right now is naming a plugin you'd want to build and showing where the proposals don't fit it. "I want to ship a plugin that does X — your model breaks because of Y" is gold.

Timeline

Honest version: the rebrand-plus-foundation milestone is ambitious. The rebrand workstream alone is non-trivial; pairing it with a substantial internal restructure means timelines will slip if both are kept tight. Workstream A (rebrand) is gated; Workstream B (foundation) ships when it's ready or moves to a later 10.x minor.

The rebrand and plugin foundation ship as ordinary, non-breaking 10.x releases. The public plugin SDK follows once the project decides to cut v11, after the foundation has been dogfooded for some weeks. We'll update this section when that decision firms up.

What this roadmap doesn't cover

  • The full backlog of bug fixes, polish, and incremental improvements outside the plugin-architecture theme. See open issues for those.
  • CI provider revival (Azure Pipelines, GitLab, TeamCity, etc.) — tracked as demand-driven in the CI roadmap milestone.
  • Continuous Delivery (deployment orchestration, environment promotion, release tracking) — see the Continuous Delivery vision milestone for the placeholder RFC.
  • Long-tail design discussion without a release target — see the Backlog milestone.

Versioning and stability promises

A note on what we are and aren't committing to:

  • The foundation milestone is "foundation laid," not "stable plugin contract." The internal interfaces shaped during it may change without notice. Do not take a dependency on them via reflection or InternalsVisibleTo — there will be no compatibility support for that path. (Not-yet-stable public surface that does ship is marked [Experimental("FALLOUT0xx")] — opt-in, and free to change.)
  • The plugin SDK's Fallout.Plugin.Sdk is the stable contract. Once 1.0 ships, the additive-only minors / breaking-changes-only-in-majors policy in RFC #3 governs every change.
  • The consumer-facing build DSL (class Build : FalloutBuild, [Parameter], [Solution], Target X => _ => _.DependsOn(...).Executes(...), static tool facades like DotNetBuild(...)) stays stable across the foundation and SDK milestones. The internal restructure does not change how you author a _build.csproj.