What are the plans for tamp going forward?

[avidenic]

Hi @BrewingCoder, really impressive work on tamp. The design (mandatory dry-run, typed secrets, the security-scanner satellites, host-aware execution) and the ADRs and roadmap are genuinely interesting.

We're evaluating tamp as a possible replacement for our NUKE-based build (now that nuke-build/nuke is deprecated), so I wanted to ask about direction before committing.

There was a big burst of activity at launch in mid-May, and I can see a v2 roadmap, but the repo has been quiet since late May. A few questions:

• Is tamp actively maintained going forward? What's the near-term plan after the initial release wave?
• Where do the two roadmap items most relevant to us stand: the nuke-to-tamp migration tool, and the Tamp.Components interface-composition mechanism (the "Tier 3" item in the migration guide)?
• Is outside contribution welcome?

Thanks for building this in the open.

[BrewingCoder]

We are actively using tamp for several projects; we have not found any issues that require changes to the current code base.

Our current focus is on reporting (attestation) and testing with our current projects. Those projects are private, for clients, but seeing 10+ PRs per day, tamp builds for dev,test,and prod environments, etc.

Outside contributes are always welcome, and the ADRs specifically talk to that point.

I'm more than happy to discuss any particular focus items. The components interface is pretty well laid out. If there's something specific you want to discuss regarding that let me know.

[BrewingCoder]

Just a further follow up on this since I had time to go back and review the documents; not just reply off the top of my head.

1. for the tamp.components; if you're referring to the notes regarding the direct replacement for Nuke.Components (IRestore, ICompile, etc.) yes that's on the roadmap but not actively in my sights at the moment; but I am totally open to contribs on that. My primary focus has been the separation of concerns; getting all the components into modules outside of the main repo.
2. Migration; I did NOT have plans to write any form of migration tool to get FROM Nuke to tamp. I do have a migration guide out there already. Migrations are so subjective and I didn't want to get into the rabbit hole of trying to support a myriad of users and their specific migration issues. We're all developers here; and I think Tamp is pretty easy to use if you are.
3. I need to update the readme and docs here. They are behind the actual code base. I'll work on updating the documents so you can see the current state.

-S

[BrewingCoder]

Following up properly on your second question; I skimmed past it the first time.

Housekeeping first: the README and wiki were badly out of date and I've just
pushed a reconcile. They said Tamp.Core 1.11.1; we're at 1.13.0. The docs were
also missing about seven shipping packages, and the roadmap still listed the
NUKE and Cake migration guides as future work when they'd already shipped. If
the project looked stalled, that's why; the docs drifted, not the code. Current
focus is reporting and attestation.

Tamp.Components

I need to correct myself. When I said "the components interface is pretty well
laid out," I meant the module/wrapper contract, i.e. how a satellite plugs into
the framework. That part is solid.

That's not what you asked. You asked about Nuke.Components: IRestore, ICompile,
ITest, IPack, IHazSolution; interface mixins that hand you pre-composed targets.
Tamp doesn't have that. It's a candidate in ADR 0001 and it's on the v2 list,
but it is not designed, not built, and not scheduled. Our own migration guide
says so and I contradicted it; I've rewritten that section to stop calling it a
"Tier 3 plan," which reads as scheduled.

So, no hedging: it's the biggest gap for a NUKE migration, and today you'd write
those targets by hand.

I want to move on it, and I want you in on it

Here's my problem: none of my projects use anything components-shaped. If I
design this alone I'm guessing; I'd be inventing opinions about which mixins
earn their keep with no real build behind them. That's how you ship a
pre-composed bundle nobody wants and can't remove, which is the failure mode
ADR 0001 was staging late to avoid.

You have what I don't: a real NUKE build that leans on components. You know
which ones pull their weight and which ones you had to fight.

What I'd want to work through:

• Which components you actually use, and which you'd drop given the chance.
• Whether the mixin shape is even right for Tamp, or whether it's a NUKE
  workaround for a problem Tamp doesn't have. Genuinely open; I don't want to
  import the pattern just because it's familiar.
• How composition interacts with what Tamp has and NUKE doesn't: CommandPlan
  dry-run, the Secret type, host preflight (RequiresDocker / RequiresNetwork).
• Whether it lands in Tamp.Core or a separate Tamp.Components package. ADR 0001
  leans separate, on the grounds that it's opinionated and Core isn't.

Mechanics are deliberately low friction: open a PR against docs/adr/ with an ADR
marked Status: Proposed. Anyone can propose one (ADR 0009 §3.1); no CLA, no
gatekeeping; lazy consensus carries it after 7 days. If you'd rather talk it
through here and let me write the ADR from that, equally fine. I want the input,
not the pen.

Two other things since you're evaluating:

• Migration tool: there isn't one and I've never scoped one. There's a guide,
  and it's honest about the gaps, but conversion is manual. I don't think a
  converter is worth building; NUKE builds are C# and it'd be brittle. Happy to
  be argued out of that.
• Other gaps: I've added a "Known gaps" section to the README so you don't
  find them mid-migration. Wrapper codegen isn't built (hence the NetCli
  V8/V9/V10 duplication), logging is in-house rather than Serilog, and we don't
  generate CI YAML on purpose.

If Components is what's standing between you and moving off NUKE, I'd rather
build it with you than have you discover in six months that it never landed.
What does your components usage actually look like?

[avidenic]

Oh wow, tnx for detailed answer. As you have guessed, we are currently in a pickle because of NUKEs deprecation. We are evaluating potential candidates. So far doing nothing seems to be the lowest hanging fruit, but this will not be the case forever. I am sure we are not the only one doing this. If I may offer a suggestion - having some activity on repo (at least active renovate / depedanbot) might attract adopters / contributors (if that is what you want). Of course, it is the worst kind of a problem - the chicken-or-an-egg problem.