Version management

Two version lines, never confused

There are two versions in play in a CodeCanyon project, and confusing them is how upgrades go sideways. One is the vendor’s version — the author’s release line, which you don’t control. The other is your fork’s version — the line you assign to your changes on top of theirs. Keeping the two clearly separated tells you, at any moment, exactly which set of changes you’re looking at.

The two lines side by side

graph TD
  subgraph Vendor["Vendor's line (you don't control it)"]
    AV1["author-v1.0.0"] --> AV2["author-v1.1.0"] --> AV3["author-v2.0.0"]
  end

  subgraph Yours["Your fork's line (SemVer you assign)"]
    Y1["v1.0.0"] --> Y2["v1.1.0"] --> Y3["v1.2.0"]
  end

  AV1 -.->|you build on top of| Y1

	Vendor’s line	Your fork’s line
Looks like	author-v1.0.0, author-v2.0.0	v1.0.0, v1.1.0
Who sets it	The CodeCanyon author	You
What it marks	A frozen snapshot of vendor code as shipped	Your changes layered on top
Why it exists	So you can always diff back to pristine vendor code	So you can track and roll back your work

The author- prefix is the tell: anything starting with author- is a snapshot of the vendor’s code exactly as they shipped it — your safety net to diff against. Anything without the prefix is yours.

SemVer for your fork

Your line follows Semantic Versioning — three numbers, MAJOR.MINOR.PATCH, each with a precise meaning:

MAJOR . MINOR . PATCH
  2   .   1   .   3
  │       │       └── bug fixes only
  │       └────────── new features, backward compatible
  └────────────────── breaking changes

You changed…	Bump	Example
Something that breaks existing behavior (renamed a config key, changed an API)	MAJOR	1.4.2 → 2.0.0
A new feature that doesn’t break anything	MINOR	1.4.2 → 1.5.0
A bug fix or typo, nothing new	PATCH	1.4.2 → 1.4.3

The discipline that makes this useful: bump the version and record the change in a CHANGELOG at the same time. A version number with no story behind it tells you nothing six months later.

CHANGELOG discipline

Keep a CHANGELOG.md where every version has a dated entry grouped by the kind of change. This is the difference between an upgrade you understand and one you fear:

# Changelog

## [1.2.0] - 2026-06-09

### Added
- New page-view tracking event

### Changed
- Better error handling on API timeouts

### Fixed
- Date parsing crash on null values

## [1.1.0] - 2026-05-20

### Added
- Consent management support

The standard categories, and when to reach for each:

Category	Use when
Added	A new feature
Changed	An existing feature behaves differently
Deprecated	A feature will be removed soon
Removed	A feature is gone in this version
Fixed	A bug fix
Security	A security-related change

Tip

Write the CHANGELOG entry as you make the change, not at release time. Reconstructing weeks of edits from memory is exactly the pain this discipline exists to prevent.

How the two lines meet at upgrade time

The payoff of keeping the lines separate shows up when the vendor ships an update. Because you have a frozen author-vX.X.X snapshot, you can diff the new vendor release against it to see exactly what they changed — and because your fork’s SemVer + CHANGELOG records what you changed, you can reason about the two sets of changes independently instead of as one tangled mess.

The size of your fork’s bump after an upgrade depends on how the vendor’s change lands:

• Backward-compatible vendor change you absorb cleanly → a MINOR or PATCH bump on your line.
• Breaking vendor change that forces you to adjust your own modules or customizations → read your CHANGELOG, plan the work, and cut a MAJOR bump.

When you need to undo

Version discipline is also what makes rollback calm. There are three levels, smallest first:

graph TD
  Issue["Something's wrong"]
  Issue --> L1["Config disable<br/>flip the .env toggle off"]
  L1 -->|not enough| L2["Code rollback<br/>git revert to the last good commit"]
  L2 -->|not enough| L3["Full rollback<br/>redeploy the previous release"]

1. Config disable — flip a module’s .env flag to false and clear the config cache. The module stops instantly, no code change.
2. Code rollback — git revert to the last known-good commit on your line. Your SemVer tags make “last known-good” easy to find.
3. Full rollback — if you use zero-downtime deploys, redeploy the previous release wholesale.

You reach for the smallest level that fixes the problem — most issues never get past level 1.

When to use which bump

Your change is…	Bump	Also do
A typo or bug fix	PATCH	CHANGELOG → Fixed
A new, backward-compatible feature	MINOR	CHANGELOG → Added
A breaking change	MAJOR	CHANGELOG → Changed/Removed + an upgrade note

Where to go next

Schema management The database side of the vendor-vs-yours seam.

Back to the concepts hub All four mental models in one place.