A minor version is the middle number in a three-part version identifier such as 2.6.1 or 11.41.0. Under Semantic Versioning (SemVer), the most widely used convention for numbering software, it rises when a product gains functionality "in a backward compatible manner". The first number, the major version, signals changes that can break existing integrations; the last, the patch, signals bug fixes. The minor number exists to tell anyone who depends on a piece of software that something new has arrived and that, in principle, nothing they already rely on has stopped working.

In advertising technology the distinction carries money. Exchanges, demand-side platforms (DSPs), header bidding wrappers and video players talk through shared specifications and libraries. Whether a release is labelled 2.6 or 3.0 decides whether hundreds of companies must rewrite code, and whether old and new systems can still trade.

How the number works

The SemVer 2.0.0 specification sets the rules. A minor version must be incremented when backward-compatible functionality is added to the public interface, and it "MUST be incremented if any public API functionality is marked as deprecated". When the minor number rises, the patch number resets to zero, so 1.4.7 becomes 1.5.0. When the major number rises, both reset, so 1.5.0 becomes 2.0.0.

Deprecation is the minor version's quieter job. The specification's FAQ says that before functionality is removed in a new major release, "there should be at least one minor release that contains the deprecation". A minor release is therefore where warnings appear, and a major release is where the warned-about features disappear.

Versions beginning with zero, such as 0.9.3, are an exception: SemVer states that "anything MAY change at any time" there. Pre-release labels also attach to the full number: 1.5.0-beta.1 sorts before 1.5.0, as PPC Land's explainer on alpha describes.

Package managers act on the convention automatically. In npm, the registry used for JavaScript, a dependency written as ^11.0.0 is a caret range, which according to the node-semver documentation allows changes that do not modify the left-most non-zero element. A publisher's build that pins ^11.0.0 will pick up 11.41.0 without anyone editing a file, but never 12.0.0. Minor releases flow in by default; that is the trust the number asks for.

Minor versions across ad tech

OpenRTB. IAB Tech Lab's real-time bidding protocol followed the textbook pattern for a decade. Versions 2.1 in January 2012 through 2.5 in December 2016 and 2.6 in April 2022 added objects and fields while keeping older bid requests valid; OpenRTB 3.0, opened for comment in September 2018, was the incompatible rebuild. From release 2.6-202211, IAB Tech Lab changed course. According to the specification's GitHub repository, the version number "is only incremented on breaking changes", non-breaking fields arrive in roughly monthly releases tagged with a date code, and "OpenRTB 2.7 should be considered a distinct version from OpenRTB 2.6". The middle digit, once the place for additions, now marks a break. PPC Land's OpenRTB explainer covers the protocol itself.

VAST. The Video Ad Serving Template moved through 4.0 in January 2016, 4.1 in November 2018, 4.2 in June 2019 and 4.3 in December 2022, as set out in PPC Land's VAST explainer. Point releases have not been small. VAST 4.1, opened for comment in June 2018, removed all references to Flash, began deprecating the VPAID interactive interface and added AdServingID as a new required field.

TCF. IAB Europe's Transparency and Consent Framework numbers its specification 2.0, 2.1, 2.2, 2.3 and 2.4, yet the Version field inside every TC String has stayed at 2 since August 2019. Compatibility is tracked by a separate TcfPolicyVersion field. When TCF v2.2 raised the policy version to 4 in May 2023, the specification declared that strings created with a lower policy version would be invalid after September 30, 2023, forcing consent to be collected again.

Prebid.js. The open-source header bidding library aims for a weekly release, according to its release schedule file, and asks contributors to label each pull request major, minor or patch. Since version 1.0 in December 2017, npm records show majors roughly once a year: 10.0.0 on July 1, 2025 and 11.0.0 on March 12, 2026. The 10.x line reached 10.29 before version 11 shipped. Legacy branches still receive fixes; 10.29.2 was published on October 6, 2026.

Google Ads API. Google has formalised the idea for advertisers' own developers. Since January 2026, the API ships monthly: four majors a year, each live for one year, with minor releases in between that "only add incremental new non-breaking features", according to the Google Ads developer blog of September 4, 2025. Google's versioning guide says a minor version updates the existing major endpoint in place, so v25.1 is served at the same /v25 address as v25. Minor versions retire with their parent: v19, v19.1 and v19.2 all stopped working on February 11, 2026.

Browsers and platforms. Chromium uses four parts, MAJOR.MINOR.BUILD.PATCH. According to the Chromium project, major and minor numbers are "a scheduling or marketing decision rather than anything about the code itself", and the version file in its source tree read 157.0.8102.0 in October 2026, with the minor fixed at zero. Meta labels each Graph and Marketing API release with a .0 suffix, such as the v21.0 release of October 2024, and retires whole versions on fixed dates.

Origin and evolution

Dotted version numbers long predate any formal rule, each vendor applying its own logic. Tom Preston-Werner, a co-founder of GitHub, published a first draft of Semantic Versioning in June 2011 and version 2.0.0 in 2013, turning a loose habit into a written contract.

Large platform owners adapted rather than adopted. Google's API design guidance, AIP-185, states that its APIs "must not expose minor or patch version numbers"; consumers see only v1 or v2, and additions arrive silently. The Google Ads API is an exception that publishes minor numbers while serving them from the major endpoint. Others have moved to dates: CalVer, a convention documented since 2016, builds versions from the calendar, as in Ubuntu 26.04, and OpenRTB's 2.6-YYYYMM tags borrow the same idea.

Why it matters

For publishers, buyers and their developers, the minor number is a planning signal. A minor bump in a bidding library or reporting API should be absorbable without a project; a major bump is a budget line. Google's move to four Ads API majors a year means a tool built against one version must migrate within twelve months, while minor releases deliver new reporting fields in between. The v24 release of April 2026, for instance, was followed by v24.1 in May and v24.2 in June.

Specification point releases also govern what can be traded. Amazon DSP began returning VAST 4.0 to 4.3 on third-party supply in 34 markets on September 2, 2026, negotiating per ad opportunity and falling back to VAST 2 or 3 where a player supports nothing newer.

Limitations and disputes

The promise of compatibility is self-certified. Nothing checks that a minor release is harmless before it is published, and ad tech offers counterexamples. On August 27, 2025, Prebid.js 10.9 made transaction identifiers bidder-specific. IAB Tech Lab said the same day that the change undermined OpenRTB, and Ari Paparo, chief executive of Marketecture, wrote that "Prebid.org pushed out a breaking change to Prebid.js", as PPC Land reported. The code interface was intact; the meaning of the data was not.

Google's v25.1 shows a similar tension. According to a Google Ads developer blog post of July 20, 2026, from v25.1 onward setting enable_local to false on a Shopping campaign returns an OPERATION_NOT_PERMITTED_FOR_CONTEXT error, while earlier versions silently treat the value as true. Google also reserves the right to switch releases "between major and minor versions".

Adoption lag is the second problem. A minor release adds capability only for those who upgrade. An April 2026 IAB Spain guide found most platforms still on OpenRTB 2.5 or 2.6, and analysis from the Cape validation tool, published by Alliance Digitale on March 12, 2026, put VAST 2 at 41.4% of declared publisher compatibility against 3.7% for 4.2. IAB Tech Lab's response, a CTV addendum retrofitting VAST 4 features into versions 2 and 3, effectively conceded that version numbers had not driven upgrades.

The numbers also mean different things in different places: a TCF "2.2" can invalidate consent, an OpenRTB "2.7" would be breaking and a Chrome minor carries no information.

Not the same as

Major version. The first number. It signals incompatible change and resets the minor and patch to zero. OpenRTB 3.0 and Prebid.js 11.0 are majors.

Patch release. The third number, reserved for backward-compatible bug fixes with no new functionality, such as Prebid.js 10.29.2.

Beta. A maturity label, not a position in the number. A beta can precede any release, written as 2.0.0-beta.1, and signals that the release is not yet stable.

Calendar versioning. CalVer encodes when something was released, not what changed. In Ubuntu 26.04 the second number is a month, and OpenRTB's date codes record a release month without asserting compatibility.

Recent developments

Release cadence is accelerating. The Google Ads API published v25 on July 22, 2026 and v25.1 on August 19, and Prebid.js reached 11.41.0 on October 8, 2026, adding modules such as the DevTools module for AI agents in 11.29.0. OpenRTB's latest dated release, 2.6-202606, arrived on June 11, 2026 without changing the version number. TCF v2.4 was published on July 23, 2026, with web deadlines for consent management platforms on October 23, 2026. On October 5, 2026, Apple's John Wilander asked The Trade Desk to test an iOS 27.2 beta after a WebKit change blocked requests to its ad domain.

Timeline

  • June 2011 - Tom Preston-Werner publishes the first draft of Semantic Versioning
  • January 2012 - OpenRTB 2.1 adopted by the IAB
  • 2013 - Semantic Versioning 2.0.0 published
  • January 21, 2016 - VAST 4.0 released
  • December 2016 - OpenRTB 2.5 released
  • December 2017 - Prebid.js 1.0 released
  • September 2018 - OpenRTB 3.0, a non-compatible major, opens for public comment
  • November 2018 - VAST 4.1 finalised, removing Flash and adding a required AdServingID
  • June 2019 - VAST 4.2 released
  • August 2019 - TCF v2.0 published; the TC String Version field is set to 2
  • April 2022 - OpenRTB 2.6 published
  • November 2022 - OpenRTB 2.6-202211 introduces date codes; version number reserved for breaking changes
  • December 2022 - VAST 4.3 finalised
  • May 2023 - TCF v2.2 raises the policy version to 4
  • September 30, 2023 - TC Strings with policy version below 4 become invalid
  • April 2024 - IAB Tech Lab drafts a CTV addendum retrofitting VAST 4 features into VAST 2 and 3
  • July 1, 2025 - Prebid.js 10.0.0 published
  • August 27, 2025 - Prebid.js 10.9 makes transaction IDs bidder-specific
  • September 4, 2025 - Google announces monthly Google Ads API releases with minor versions
  • February 11, 2026 - Google Ads API v19, v19.1 and v19.2 sunset together
  • March 12, 2026 - Prebid.js 11.0.0 published
  • April 22, 2026 - Google Ads API v24 released
  • July 22, 2026 - Google Ads API v25 released
  • August 19, 2026 - Google Ads API v25.1 released
  • September 2, 2026 - Amazon DSP begins serving VAST 4.0 to 4.3 on third-party supply
  • October 8, 2026 - Prebid.js 11.41.0 published

Summary

Who: Software maintainers and standards bodies assign minor versions: IAB Tech Lab for OpenRTB and VAST, IAB Europe and IAB Tech Lab for TCF, Prebid.org for Prebid.js, and platform owners such as Google, Meta and the Chromium project. Developers at exchanges, DSPs, publishers and agencies consume them.

What: The middle number in a MAJOR.MINOR.PATCH version, which under Semantic Versioning signals new, backward-compatible functionality or a deprecation, and resets the patch number to zero.

When: Dotted numbering is decades old; SemVer codified it between 2011 and 2013. Ad tech standards applied it from OpenRTB 2.1 in 2012, and from November 2022 OpenRTB stopped using the minor number for additions.

Where: In specification names, library releases, API endpoints and dependency files, and in bid request headers such as x-openrtb-version, where a receiving system decides how to parse what it has been sent.

Why: To tell integrators whether an update can be absorbed safely. In ad tech that promise is often bent: point releases can add required fields, invalidate consent or change the meaning of data, and adoption lags years behind publication.