Skip to main content
Guides

Tag timestamps

Why ReleaseJet cares when a tag was created.

ReleaseJet picks the issues for a release by comparing each issue's closedAt against the creation timestamp of the current and previous tags. Understanding how tag timestamps are resolved matters when you troubleshoot missing or extra issues.

Three timestamp sources

Every tag ReleaseJet sees resolves to one of three sources:

  • annotated — the tag has a tag object with its own timestamp. Exact timing.
  • release — a Release (GitHub) or Release object (GitLab) is attached to the tag. Exact timing.
  • commit — lightweight tag with no annotation and no release. Falls back to the underlying commit's date.

The first two are precise. commit is the one to watch — the commit date is whenever the commit was authored, not when you tagged it, so you can end up including issues closed after the commit but before the tag was pushed.

How the window is built

For the current tag:

  • annotated or release → upper bound is the tag's timestamp.
  • commit → upper bound is expanded to the next same-prefix tag's timestamp, or now() if there is no later tag.

For the previous tag, the lower bound uses its resolved createdAt. The API query itself uses the previous tag's commit date (always ≤ the actual tag time) as a pre-filter, and ReleaseJet applies the exact closedAt window client-side. The two-layer approach avoids dropping issues that were edited between the commit and the tag push.

Making tags precise

To guarantee exact timing, pick one:

Annotated tag:

git tag -a v1.0.0 -m "Release v1.0.0"
git push origin v1.0.0

Release object:

  • GitLab: Code → Tags → New tag → fill the Message field.
  • GitHub: Releases → Draft a new release → choose or create the tag → Publish.

Let ReleaseJet do it:

releasejet generate --tag v1.0.0 --publish

Publishing creates a release object, which ReleaseJet resolves precisely on subsequent runs.

Re-tagging

Moving a tag (delete + recreate) changes its timestamp. Issues that used to fall inside the release window may now fall outside, or vice versa. If you need to re-tag, re-run generate --publish to rewrite the release notes for the new window.

Troubleshooting

  • "Tag is lightweight" warning — the current tag resolved to commit. Re-tag with -a, create a Release, or run --publish to upgrade to release.
  • Unexpected issue included — likely a commit-sourced tag pulled in activity from after the intended cut-off. Check the --debug output for "Upper bound" and its source.