Designing a Structured Firmware Version Number Format

Previously I wrote an article on automatically printing version information from a C program; the goal was to ensure the program reports its version at runtime to avoid mismatches during testing. This piece fills the promised gap by describing a relatively standardized firmware version number format.

Mirror Version Number Format

The format consists of three main parts:

Project name (e.g., YIKOU3568, YIKOU4412)

Firmware version (detailed in the next section)

Comments (optional descriptors such as OS, hardware platform, or Git commit ID)

Firmware Version Detailed Format

The firmware version string follows the pattern vXX.YY.YYMMDDN_T where each field is defined as follows:

Name

Format

Length (bytes)

Description

v

v

1

Version string starts with the letter "v"

Major

XX

2

Major version number (00: engineering sample, 01: feature complete, 02~: commercial release). Incremented for major codebase changes or new features after commercial release.

Minor

YY

2

Minor version for bug fixes or small feature additions (requires release notes if increased).

build ID

YYMMDDN

7

Build identifier: Y‑year, M‑month, D‑day, N‑nth build of the day (0,1,2… a,b,c… x,y,z).

release type

T

0‑1

Optional release type flag; "T" indicates a testing version.

Example

Consider a firmware release with the following characteristics:

Project name: YIKOU3568

Project is functionally complete but not yet commercially released.

Minor version incremented from 5 to 6 to fix bugs.

Build date: 2024‑09‑09

Second build of the day.

Release type: testing (T).

Corresponding fields:

project name: YIKOU3568

major: 01

minor: 06

build ID: 240909

N: 1

release type: T

Resulting version string:

YIKOU3568_v01.06.2409091_T

In practice, teams can adapt individual fields to suit their needs.

Final Recommendations

Ensure that each released firmware image is linked to the exact Git commit it was built from. Before publishing, delete any local copies, pull the latest code from the server, perform a clean build, run a basic test, and only then release the version. This guarantees traceability and helps close bug loops when issues arise.