A changelog video belongs on the same checklist as the tag, the notes and the binaries. Check out the release on disk, brief the one change users will notice, review the script, export what you need, then attach the wide cut to the GitHub release before you share anywhere else. Ship it with the tag, not as a follow-up.
Key takeaways
- Put the video on the release checklist so it ships with the tag.
- One change per video. A tour of every bullet loses people fast.
- Build from the checked-out tag on your machine, not from a release URL alone.
- Attach the 16:9 file to the release or changelog page. Save vertical cuts for social.
- Keep a human on the script. Auto-start on every tag is not worth the risk.
Contents
- Why does a changelog video belong on the release checklist?
- What steps should the checklist include?
- How do you build the video from the tagged code?
- Where does each export format go?
- What should stay manual?
- FAQ
Why does a changelog video belong on the release checklist?
The tag is the moment you already decided what changed. The notes are open and someone is about to publish. That is the cheapest time to show the change on screen.
A video written days later usually drifts: a different highlight, a moved UI on main, or a task that never gets scheduled. Attaching the file to the release makes the gap visible. If the asset is missing, the checklist is not done.
Text notes still matter. The clip answers what people ask after they skim the bullets: what does this look like when I click it?
What steps should the checklist include?
Keep it short enough for release day.
| Checklist step | Done when | Owner |
|---|---|---|
| Tag is on disk | Fetch and checkout of the release tag succeed | Release cutter |
| One-line brief written | One sentence names the user-visible change | Release owner or PM |
| Script reviewed | First line states what changed; internals cut | Same person |
| Preview watched once | No wrong screen or leftover sample copy | Same person |
| Wide file attached | Release or changelog page links the MP4 | Release owner |
Name an owner for each step. Unowned steps skip the first busy week.
How do you build the video from the tagged code?
Check out the tag first
A local build-from-code workflow needs the release folder on your machine, not main from this morning.
git fetch origin git checkout v2.4.0 Point the workspace at that folder. If the tool cannot take a GitHub URL, that is expected: "from a release" means "from this tag on disk."
Brief one change
Write one sentence for the change a customer will notice, for example "Show the new bulk export on the Reports page." Paste only the matching notes. Ten bullets in one video become a slideshow nobody finishes.
More on short release clips: why release notes work better as videos. The DemoVexa walkthrough: how to turn a GitHub release into a changelog video.
Review, export, attach
Read the script as a customer. Cut migrations, flags and internal names. The first line should say what is new. Render the wide cut first, with SRT or VTT if needed. Add vertical versions only for feeds.
Prefer the terminal? The product demo video CLI covers install and start. Someone still approves the script.
Where does each export format go?
- 16:9 MP4: GitHub release assets, changelog page, docs, YouTube.
- 9:16 MP4: Shorts, Reels, stories. One moment from the same change.
- 1:1 MP4: Feed posts that crop awkward widescreen frames.
- SRT / VTT: Upload wherever the platform indexes captions.
Readers on a laptop want the wide cut, not a vertical file in the notes.
What should stay manual?
Script approval. A changelog video goes to customers. Auto-start on every tag sounds neat until a half-finished feature name ships in the voiceover.
Rendering can wait overnight. A human still opens the preview, fixes one line if needed, and publishes.
DemoVexa builds the script and screens from the local code folder, then exports those formats with captions. See the features page. There is no GitHub Action that starts a video on publish today, and I would still want a person on the script even if there were.
FAQ
Can I point the tool at a GitHub release URL?
Only if it supports that. DemoVexa does not. Clone, check out the tag, and point a workspace at that folder.
How long should the changelog video be?
Long enough to show one change and why it matters. Most fit in about 30 to 60 seconds.
Do I need to record my own voice?
No. Use an AI voice on your own key, record yourself, or ship captions only.
Should every release get a video?
Only when there is a user-visible change worth showing. Skip dependency bumps and internal refactors.
Where should I link the video in the release body?
Near the top, next to the headline change.
Can the same project cover social cuts later?
Yes. Export 9:16 or 1:1 from the approved project later, instead of rebuilding from another commit.
Baltej Singh is the founder of DemoVexa, a desktop app and CLI that turns a local codebase into narrated product demo videos. He writes from Delaware, USA.
