fristy/VERSIONING.md

Versioning Strategy

Semantic Versioning (SemVer)

Dieses Projekt folgt Semantic Versioning 2.0.0

Format: MAJOR.MINOR.PATCH

1.2.3
│ │ └─── PATCH: Bugfixes, keine Breaking Changes
│ └───── MINOR: Neue Features, abwärtskompatibel
└─────── MAJOR: Breaking Changes, nicht abwärtskompatibel

Version-Nummern

MAJOR (X.0.0)

Erhöhen wenn:

• Breaking Changes an der API
• Fundamental neue Architektur
• Entfernung von Features
• Nicht-kompatible Änderungen

Beispiele:

• 1.0.0 → 2.0.0: Neue Auth-Struktur, alte Tokens funktionieren nicht mehr
• 2.0.0 → 3.0.0: Kompletter UI-Rewrite

MINOR (0.X.0)

Erhöhen wenn:

• Neue Features hinzugefügt
• Neue Screens/Module
• Abwärtskompatible Funktionalität

Beispiele:

• 0.1.0 → 0.2.0: Neues Notifications-Modul
• 1.0.0 → 1.1.0: Export-Funktion hinzugefügt
• 1.1.0 → 1.2.0: Dokumenten-Upload implementiert

PATCH (0.0.X)

Erhöhen wenn:

• Bugfixes
• Performance-Verbesserungen
• UI-Anpassungen ohne neue Features
• Dependency-Updates

Beispiele:

• 0.1.0 → 0.1.1: Login-Fehler behoben
• 1.0.0 → 1.0.1: Crash beim Laden behoben
• 1.0.1 → 1.0.2: Performance optimiert

Pre-Release Versionen

Alpha (0.0.x-alpha.y)

• Sehr frühe Entwicklungsphase
• Instabil, viele Bugs erwartet
• Nur für interne Tests

0.0.1-alpha.1
0.0.1-alpha.2

Beta (0.x.0-beta.y)

• Feature-komplett
• Testing-Phase
• Kann noch Bugs haben

0.1.0-beta.1
0.1.0-beta.2
1.0.0-beta.1

Release Candidate (x.x.x-rc.y)

• Bereit für Release
• Nur kritische Bugfixes
• Letzte Tests vor Production

1.0.0-rc.1
1.0.0-rc.2

Build Metadata

Optional für zusätzliche Informationen:

1.0.0+20231117
1.0.0+build.123
1.0.0-beta.1+exp.sha.5114f85

Version Timeline für Fristy

Phase 1: Initial Development (0.0.x)

0.0.1 - Projekt-Setup, Architektur
0.0.2 - Auth Screens
0.0.3 - Contract CRUD
0.0.4 - Dashboard

Phase 2: MVP (0.x.0)

0.1.0 - Alpha Release (interne Tests)
0.2.0 - Beta Release (geschlossene Beta-Tester)
0.3.0 - Release Candidate

Phase 3: Public Release (1.0.0)

1.0.0 - Erster öffentlicher Release
1.1.0 - Dokumenten-Upload
1.2.0 - Erweiterte Statistiken
1.3.0 - Export-Funktion

Phase 4: Advanced Features (2.0.0)

2.0.0 - Neues Backend, OCR-Feature
2.1.0 - Familie/Team-Sharing
2.2.0 - Kündigungs-Assistent

Version in Code

package.json

{
  "version": "0.0.1"
}

App-Anzeige

// src/shared/constants/index.ts
export const APP_VERSION = '0.0.1';
export const BUILD_NUMBER = '1';

Native Code

iOS (Info.plist):

<key>CFBundleShortVersionString</key>
<string>0.0.1</string>
<key>CFBundleVersion</key>
<string>1</string>

Android (build.gradle):

versionName "0.0.1"
versionCode 1

Git Workflow

Branch-Strategie

main (production)
├── develop (development)
│   ├── feature/user-auth
│   ├── feature/contract-crud
│   └── feature/dashboard
├── release/v1.0.0
└── hotfix/critical-bug

Commit-Message Format

type(scope): subject

[optional body]
[optional footer]

Types:

• feat: Neues Feature
• fix: Bugfix
• docs: Dokumentation
• style: Formatierung, keine Code-Änderung
• refactor: Code-Refactoring
• test: Tests hinzufügen/ändern
• chore: Build-Prozess, Dependencies

Beispiele:

feat(auth): implement login screen
fix(contracts): resolve date parsing issue
docs(readme): update installation steps
refactor(store): simplify contract selectors

Release-Prozess

1. Feature entwickeln:

   git checkout develop
   git checkout -b feature/mein-feature
   # ... entwickeln ...
   git commit -m "feat(module): beschreibung"
   git push origin feature/mein-feature
   

2. Release vorbereiten:

   git checkout develop
   git checkout -b release/v0.1.0
   # Version-Nummern aktualisieren
   # CHANGELOG.md aktualisieren
   git commit -m "chore(release): bump version to 0.1.0"
   

3. Release durchführen:

   git checkout main
   git merge release/v0.1.0
   git tag -a v0.1.0 -m "Release v0.1.0"
   git push origin main --tags
   

4. Hotfix (falls nötig):

   git checkout main
   git checkout -b hotfix/critical-bug
   # ... fix ...
   git commit -m "fix(auth): critical security issue"
   git checkout main
   git merge hotfix/critical-bug
   git tag -a v0.1.1 -m "Hotfix v0.1.1"
   

Version-Updates

Automatisch mit npm

# PATCH: 0.0.1 → 0.0.2
npm version patch

# MINOR: 0.0.1 → 0.1.0
npm version minor

# MAJOR: 0.1.0 → 1.0.0
npm version major

# Pre-Release
npm version prerelease --preid=alpha
npm version prerelease --preid=beta
npm version prerelease --preid=rc

Manuell

1. package.json - version
2. src/shared/constants/index.ts - APP_VERSION
3. ios/Fristy/Info.plist - CFBundleShortVersionString
4. android/app/build.gradle - versionName
5. CHANGELOG.md - neue Version dokumentieren

Best Practices

✅ DO

• Version-Bump bei jedem Release
• CHANGELOG.md aktuell halten
• Semantic Versioning strikt befolgen
• Tags für alle Releases
• Build-Number bei jedem Build erhöhen

❌ DON'T

• Version-Nummern überspringen
• MAJOR-Bump für kleine Changes
• Ohne Tag releasen
• CHANGELOG vernachlässigen
• Inkonsistente Versionen (iOS ≠ Android)

Tools & Automation

Empfohlene Tools

standard-version:

npm install --save-dev standard-version

# In package.json
"scripts": {
  "release": "standard-version",
  "release:minor": "standard-version --release-as minor",
  "release:major": "standard-version --release-as major"
}

commitlint:

npm install --save-dev @commitlint/cli @commitlint/config-conventional

husky:

npm install --save-dev husky
npx husky install

App Store / Play Store

Build Numbers

iOS:

• Version: 1.0.0 (sichtbar für User)
• Build: 1, 2, 3, ... (stetig steigend)

Android:

• versionName: 1.0.0 (sichtbar)
• versionCode: 1, 2, 3, ... (Integer, stetig steigend)

Release-Zyklus

Development → TestFlight/Internal Testing → Production
   ↓              ↓                            ↓
0.1.0-beta    0.1.0-rc.1                   1.0.0

Zusammenfassung

• Aktuell: 0.0.1 (Initial Setup)
• Nächster Minor: 0.1.0 (MVP mit allen Basis-Features)
• Nächster Major: 1.0.0 (Public Release)
• Format: MAJOR.MINOR.PATCH
• Workflow: Git Flow mit develop/main
• Commits: Conventional Commits
• Changelog: Keep a Changelog Format