v0.32.1 Migration Guide

Cache becomes MemoizeSection anchor link

The result-memoization modifier .Cache() is renamed to .Memoize() on both JobNode and JobGroup. The behavior is unchanged: a key names the work, and a later node computing the same key replays the stored result instead of running. Only the name changes, and the supporting types change with it.

BeforeAfter
JobNode.Cache(key, opts...)JobNode.Memoize(key, opts...)
JobGroup.Cache(key, opts...)JobGroup.Memoize(key, opts...)
JobNode.CacheConfig()JobNode.MemoizeConfig()
sparkwing.CacheConfigsparkwing.MemoizeConfig
sparkwing.CacheOptionsparkwing.MemoizeOption

CacheKey, CacheKeyFn, Key(...), NoCache, TTL, DefaultCacheTTL, and MaxCacheTTL keep their names, because a memoized result is still stored under a content-addressed cache key. There is no deprecation alias; every call site is a compile error until updated:

shard.Cache(func(ctx context.Context) sparkwing.CacheKey {  // before
    return sparkwing.Key("coverage", "shard-1")
})
shard.Memoize(func(ctx context.Context) sparkwing.CacheKey { // after
    return sparkwing.Key("coverage", "shard-1")
})

Why: .Cache() read like GitHub Actions actions/cache and did the opposite -- it skipped the node instead of restoring a directory. .Memoize(key) now names what it does, while .CacheDir(...) keeps a dependency directory warm (the actions/cache equivalent). JobGroup.Memoize still applies one key to every member, so a JobFanOut matrix needs a key that depends on the per-member value; the group-cache-shared lint catches a constant one.