Skip to content

Versions vs. Milestones

New Fox users ask this within the first week: what's the actual difference between versions and milestones? The short answer is that they're both optional grouping containers, but they're shaped for slightly different questions. This guide is about when to reach for each — and when to skip both.

The Short Answer

A rough heuristic, loose on purpose:

  • Versions answer: what's shipping together?
  • Milestones answer: what work is this for?

If you're tracking a product release with a version number, you probably want a version. If you're tracking a feature, an initiative, or a goal with no release boundary, you probably want a milestone. If the work is just a pile of issues you'll get to eventually, you probably want neither — leave them in Unsorted.

When to Use Versions

Versions fit best when you have a natural "ship date" or release boundary. A version contains everything that goes out together. Examples:

  • v1.0, v1.1, v1.2 — Classic semantic versioning for an app or library
  • Summer Release — A marketing-aligned release that bundles several features
  • Q1 2026 — A time-boxed release cycle
  • MVP Launch — A specific target launch

Because versions can contain milestones, they're a natural fit when a release is big enough to break down further — "v2.0 has three milestones inside it: Auth, Dark Mode, and Performance."

When to Use Milestones

Milestones fit best when you have a goal without a release boundary. They're flexible groupings for related issues that make sense together. Examples:

  • User Authentication — A feature that spans many issues
  • Performance Improvements — An initiative you're running alongside other work
  • Onboarding Flow — A product area you're actively improving
  • Beta Feedback — A batch of issues collected from testers

Milestones can live inside versions (as children) or on their own at the project level. Use whichever structure matches how you think about the work.

When to Use Neither

Don't underrate the power of doing nothing. For a lot of projects — especially early ones, side projects, and personal trackers — the right structure is a flat list of issues in Unsorted. You get fast capture, zero decision overhead, and a clean surface for triage later.

Signs you're ready to add structure:

  • You're scrolling past the same issues repeatedly to find active work
  • You can name what you're working on this week as "the X feature" or "the Y release"
  • You want the board scoped to a subset of issues, not all of them

If none of those are true, stay flat.

Worked Examples

A Solo Indie App with Regular Releases

You maintain a Mac app. You cut releases every month or two, each with a version number, and each release has two or three features.

  • Versions — v3.0.4, v3.0.5, v3.1.0…
  • Milestones — Used sparingly inside bigger versions (v3.1.0 → "Dark Mode", v3.1.0 → "New Exports")
  • Unsorted — The backlog where new bug reports and ideas land before you triage them into a release

A Research Project with No Releases

You're tracking research tasks, experiments, and writing. Nothing is "shipping" — there's no release cadence.

  • Versions — None
  • Milestones — One per research thread or paper in progress ("Survey Paper", "Experiment 3", "Literature Review")
  • Unsorted — Stray ideas and questions that don't have a home yet

A Team Product with Quarters

You're working on a product with a quarterly roadmap and multiple initiatives per quarter.

  • Versions — One per quarter (Q1 2026, Q2 2026)
  • Milestones — Inside each quarter, one per initiative (Q1 2026 → "Auth Revamp", Q1 2026 → "Mobile Optimization")
  • Unsorted — The parking lot for issues not yet scheduled

A Bug Tracker With No Plan

Someone reports a bug, you fix it or close it, move on. No plan, no roadmap.

  • Versions — None
  • Milestones — None
  • Unsorted — Everything lives here

Mixing Approaches

Nothing stops you from mixing. A project might have a formal v2.0 version for its next release and a standalone Tech Debt milestone tracking ongoing cleanup work that isn't tied to any version. Use the structure for work that benefits from grouping, and leave the rest in Unsorted.

See Also