Adrenaline

TrackLang includes a Git-like version control system built directly into the browser. Every time you run or save your track, Adrenaline creates version snapshots automatically—ensuring you never lose your work and can easily experiment with changes. Understand build versions, minor versions, major versions, and how to fork tracks from the community.

Why Version Control?

Track development is iterative. You'll test ideas, discover issues, and refine layouts over time. Version control lets you:

Experiment safely: Try radical changes knowing you can always revert
Track evolution: See how your track improved from v1.0 to v2.5
Recover from mistakes: Accidentally broke something? Just roll back
Collaborate: Share tracks with others who can fork and improve them
Event continuity: Run Event #1 on v1.0, Event #2 on v1.1 with improvements

Version Types

Adrenaline uses three version types, each created automatically or manually:

Build Versions

Created: Automatically every time you click "Run"

Purpose: Temporary snapshots for active development

Build versions are like auto-save. Each time you run your TrackLang code, Adrenaline creates a build version snapshot. These aren't meant to be permanent—they're for rapid iteration during active coding sessions.

Example: v0.1.001, v0.1.002, v0.1.003
The third number increments each run.

Build versions help you recover from recent mistakes even if you haven't saved a formal version yet.

Minor Versions

Created: Manually when you click "Save New Version"

Purpose: Named, stable versions for tracking meaningful progress

Minor versions are intentional milestones. When you've made significant changes and want to preserve that state, save a new minor version. These are the versions you'll reference for events, share with others, or revert to when needed.

Example: v0.1, v0.2, v0.3
The second number increments each save.

You can add version notes when saving (e.g., "Fixed finish line camera angle, widened Turn 2").

Major Versions

Created: Manually when you decide to uptick the major version number

Purpose: Major track redesigns or seasonal layouts

Major versions represent significant changes—complete redesigns, seasonal variations, or fundamentally different layouts. You control when to increment the major version, typically for big releases.

Example: v1.0, v2.0, v3.0
The first number increments when you explicitly uptick major version.

Use major versions for: Spring vs. Summer layouts, Beginner vs. Pro variants, before/after major rebuild.

Version Number Format

Semantic Versioning: MAJOR.MINOR.BUILD

v2.5.142

MAJOR (2): Major redesign. You decide when to increment.
MINOR (5): Fifth saved version of v2.x. Auto-increments on "Save New Version".
BUILD (142): 142nd run since v2.5 was created. Auto-increments on "Run".

Tip: Build numbers reset when you save a new minor version. v2.5.142 → "Save New Version" → v2.6.001.

Workflow: Making Changes

Daily Development Cycle

Edit code - Make changes to TrackLang
Click "Run" - Creates build version, view 3D result (e.g., v1.2.015)
Iterate - See issue? Edit and Run again (v1.2.016, v1.2.017...)
Satisfied? - Click "Save New Version" when you've made meaningful progress (→ v1.3.001)
Add notes - Describe what changed in this minor version

Example Development Timeline

v1.0.001 - Initial track creation
v1.0.002 - Run: Added first turn
v1.0.003 - Run: Fixed turn radius
v1.0.004 - Run: Added second turn
v1.1.001 - Save: "Basic loop complete"
v1.1.002 - Run: Testing jump at 50m
v1.1.003 - Run: Adjusted jump height
v1.2.001 - Save: "Added table top jump"
v1.2.002 - Run: Camera angle fix
v1.3.001 - Save: "Fixed finish line camera"
...(continue iterating)
v2.0.001 - Save: "Summer 2025 layout" (major version uptick)

Viewing Version History

Access your track's complete version history from the Track Developer:

Open Track Developer for your track
Click "Version History" or "Versions" panel
See chronological list of all versions (minor and build)
Click any version to view its code or load it into the editor
Compare two versions side-by-side to see what changed

What You'll See in Version History:

Version number (e.g., v1.3.012)
Timestamp (when created)
Author (who made the change, for team tracks)
Version notes (if added for minor versions)
Code snapshot (full TrackLang code at that moment)

Reverting to Previous Versions

Made a mistake? Reverting is easy:

Option 1: Load and Save As New Version

Open Version History
Find the version you want to restore (e.g., v1.2.001)
Click "Load" to put that code in the editor
Click "Save New Version" to create v1.4.001 with the old code
Version history preserved—you haven't deleted anything

Option 2: Fork the Old Version

Find the old version you want
Click "Fork" to create a new track based on that version
Now you have two tracks: the current one and the forked restoration

No destructive operations: Version history is append-only. You can't delete versions, only create new ones. This means reverting is safe—the "bad" version still exists if you need it later.

Forking Tracks

Forking creates a copy of a track (yours or someone else's) that you can modify independently. Any public minor version can be forked by another account.

How to Fork a Track

Find a public track in the track library or community tracks
Browse its versions and select the one you want to fork (e.g., v2.3)
Click "Fork" button
Fork is created under your account as v0.1.001 (starts fresh version numbering)
Edit, run, and save as you would with your own track
Original track is unaffected—your fork is completely independent

Why Fork?

Customize community tracks: Find a track similar to yours and modify it instead of starting from scratch
Create variations: Fork your own track to test radical changes without risking the original
Seasonal layouts: Fork v1.5 to create a winter variant while keeping summer version intact
Event-specific tweaks: Fork a track, adjust for a specific event, run the event, keep both versions
Collaboration: Someone improves your public track? They fork, make changes, you can fork their fork back if you like it

Public vs. Private Tracks

Only public minor versions can be forked by others:

Public tracks: Visible in track library, anyone can fork any minor version
Private tracks: Only you (and team members) can see or fork
You choose public/private when saving a minor version
Build versions are always private (not forked directly—only minor versions)

Fork credits: Forked tracks retain attribution to the original. If you fork "Thunder Valley MX v2.3" by @user123, your fork shows "Forked from Thunder Valley MX v2.3 by @user123".

Team Collaboration

Multiple people can work on the same track by sharing permissions:

How Team Tracks Work

Track owner invites team members via email or username
Team members gain edit access to the track
Each team member can edit, run, and save versions
Version history shows who made each change
No simultaneous editing—last save wins (like Google Docs when offline)

Avoiding Conflicts

Coordinate with team: "I'm editing cameras, you do timing zones"
Use version notes to communicate: "Added Turn 3, please review"
If conflict happens, version history has both versions—fork and merge manually

Best Practices

Save often: Don't rely on build versions alone. Save a minor version when you've made meaningful progress.
Descriptive version notes: Future you will thank you. "Fixed camera angle Turn 2" is better than "updates".
Major versions for big changes: Don't uptick to v2.0 for small tweaks. Reserve major versions for significant redesigns.
Test before saving: Run and validate your changes before saving a minor version. Build versions are for experimenting.
Fork for experiments: Testing a radical idea? Fork the track instead of risking the original.
Public sharing: Make tracks public to help the community. Others can learn from and improve your work.
Version notes as changelog: Treat version notes like a changelog—document what changed so others (or future you) understand.

Example: Event-Driven Versioning

Real-World Track Evolution

v1.0 - "Spring 2024 Opening"

Initial track layout, tested with ad-hoc races
Run Event #1 (Race Weekend #1)
Feedback: Finish line camera too low, Turn 2 too tight

v1.1 - "Fixes after Event #1"

Raised finish line camera angle to 45°
Widened Turn 2 from 10m to 12m
Run Event #2 (Race Weekend #2)
Feedback: Jump at 50m too steep

v1.2 - "Jump adjustment"

Reduced jump takeoff angle from 4m to 2.5m
Run Event #3-5 successfully

v2.0 - "Summer 2024 Redesign"

Complete track redesign: added third turn, removed jump, new layout
Major version uptick because it's fundamentally different
v1.2 still available for reference or to revert if v2.0 doesn't work out

Common Questions

Can I delete old versions?

No. Version history is immutable. This is by design—you can't accidentally lose work. If you don't want others to see old versions, make the track private.

How many versions can I create?

Unlimited. Build versions are cleaned up automatically after a while to save space, but minor versions persist forever.

Can I fork a private track?

Only if you have permissions (owner or team member). Public tracks can be forked by anyone.

What happens to events using old track versions?

Events reference specific minor versions. If you run Event #1 on v1.0, then update to v1.2, Event #1 still uses v1.0. Event results are tied to the version used when the event ran.

Can I merge two versions?

Not automatically. If you have divergent versions (e.g., two team members edited separately), manually compare and merge in the editor, then save as a new version.

When should I uptick major version?

When the track is fundamentally different from previous versions—major redesigns, seasonal layouts, or when it no longer makes sense to compare to v1.x.

TrackLang: Source Control Repository