Capgo Semver Tester

Verifica la compatibilità della policy del canale rispetto alla baseline nativa inviata come version_build

Versione baseline nativa

La versione nativa inviata a Capgo come version_build, dalla config o dai metadati dell'app nativa.

Versione remota

La versione del bundle assegnata al canale risolto.

Inserisci due versioni semantiche per vedere il confronto

Cosa si intende per "Native Baseline Version"

La Native Baseline Version è la versione dell'app nativa inviata a Capgo come version_build quando il dispositivo richiede un bundle al server degli update. In un'app Capacitor, quel valore può derivare da CapacitorUpdater.version nella capacitor.config.*. Se questa impostazione non è presente, il plugin ricade sulla versione dell'app nativa di iOS o Android. Non dare per scontato che sia la tua package.json versione, a meno che il tuo build non copi quel valore nel config o nei metadati nativi.

Capgo utilizza ancora version_name per sapere quale bundle scaricato è attualmente installato. Le policy semver dei canali come major, minor, e patch confrontano il bundle remoto con version_build.

Configurazione Capacitor

Imposta CapacitorUpdater.version quando vuoi una versione esplicita inviata dall'app.

Pro: facile da mantenere uguale tra build iOS e Android.

Contro: una config obsoleta può riportare la versione errata se dimentichi di aggiornarla prima di un rilascio nativo.

Versione dell'app nativa

Usa la versione della piattaforma, come iOS CFBundleShortVersionString o Android versionName.

Pro: corrisponde al binario installato dagli utenti da TestFlight, App Store, Play Store o test interni.

Contro: modificarlo richiede una build nativa e può variare per piattaforma se le impostazioni di release divergono.

Targeting del bundle

Confrontalo con le versioni dei bundle remoti, le regole semver dei canali o i vincoli di upload dei metadati come --min-update-version. Il canale deve usare --disable-auto-update metadata.

Pro: impedisce l'invio di JavaScript che richiede un code nativo più recente a binari di app obsoleti.

Contro: regole troppo rigide possono bloccare aggiornamenti validi finché il canale o i metadati del bundle non vengono adeguati.

Per questo tester, inserisci la baseline nativa che il dispositivo invia come version_build, quindi confrontala con la versione del bundle remoto che vuoi che Capgo distribuisca.

Perché Capgo usa Semantic Versioning

Versionamento Semantico è lo standard di versioning più diffuso nello sviluppo software. Usando semver, Capgo garantisce compatibilità e sicurezza nel distribuire live update alle tue app Capacitor.

Lo standard semver permette a Capgo di capire esattamente quali modifiche sono incluse in ogni update:

Aggiornamenti patch (1.0.0 → 1.0.1): Bug fix, sicuri da applicare automaticamente
Aggiornamenti minor (1.0.0 → 1.1.0): Nuove feature, retrocompatibili
Aggiornamenti major (1.0.0 → 2.0.0): Breaking changes, richiedono un nuovo rilascio sugli store nativi

Questo impedisce a Capgo di inviare un update incompatibile alla tua code nativa, proteggendo i tuoi utenti dai crash e mantenendo l'app stabile.

Strategie semver flessibili: oltre il versioning di base

Sebbene semver sia rigoroso sul formato core, puoi estenderlo per le esigenze del tuo team usando identificatori pre-release e metadati di build:

🏷️ Metadati di build (+) - Il livello "cosmetico"

1.2.0+20240315.142530

Timestamp per il tracciamento del deployment

1.2.0+ui.refresh.dark-mode

Descrizione dell'aggiornamento UI per il team di design

1.2.0+build.4729.commit.a1b2c3d

Numero di build CI/CD e git commit

Importante: I metadati di build vengono ignorati nella precedenza di versione - 1.2.0+anything uguale 1.2.0 per la logica di update di Capgo.

🔧 Identificatori pre-release (-) - Canali di sviluppo

1.3.0-beta.1

Canale di beta testing

1.3.0-hotfix.payment

Branch per fix urgenti

1.3.0-feature.newapi

Test del branch feature

Nota: Le versioni pre-release hanno precedenza minore - 1.3.0-beta.1 < 1.3.0

🎯 Approccio ibrido - Il meglio dei due mondi

1.3.0-rc.1+ui.redesign.20240315

Release candidate con metadati UI e timestamp

Casi d'uso reali di Semver e strategie di team

🚀 Startup / Sviluppo rapido

0.1.0 - Prima release MVP

0.2.0-beta.1 - Test di nuove funzionalità

0.2.0+ui.v2 - Metadati per il redesign UI

1.0.0 - Pronta per la produzione

Usa 0.x.x per lo sviluppo pre-1.0, metadati per il tracking del design

🏢 Enterprise / Settore regolamentato

2.1.0 → Release trimestrale

2.1.1+sec.patch.cve2024 → Patch di sicurezza con tracking

2.2.0-rc.1+audit.ready → Release candidate pre-audit

Semver rigoroso con metadati di conformità

🎮 Gaming / App creative

1.0.0+season.winter.2024 → Contenuti stagionali

1.1.0+event.halloween → Funzionalità event-driven

1.2.0+assets.hd.remaster → Update degli asset

Metadata creativi per il tracking dei contenuti

⚡ Strategia Hotfix

1.2.0 → Produzione attuale

1.2.1-hotfix.payment → Fix bug critici

1.2.1+urgent.20240315.1430 → Rilasciato con timestamp

Pre-release per i test, metadata per il tracking del deployment

🌍 Strategia Multi-Platform

1.3.0+ios.optimized → Ottimizzazioni specifiche iOS

1.3.0+android.material3 → Aggiornamenti del design Android

1.3.0+web.pwa.ready → Funzionalità PWA

Stessa versione, metadati specifici per piattaforma

🔄 Integrazione CI/CD

1.4.0-alpha.1+build.123 → Pre-release automatizzata

1.4.0+deploy.staging.456 → Deployment su staging

1.4.0+prod.final.789 → Deployment in produzione

Versioning automatizzato con metadati di deployment

💡 Suggerimenti Pro:

Usa i metadati di build (+) per tracciamento, timestamp o informazioni cosmetiche che non influenzano la compatibilità
Usa gli identificatori pre-release (-) per i canali di sviluppo con priorità di aggiornamento diversa
Combina entrambi per la massima flessibilità: 1.2.0-beta.1+ui.dark.theme.20240315
Ricorda: Capgo rispetta le regole di precedenza semver, pianifica quindi la tua strategia dei canali di conseguenza

Importante: Capgo usa un semantic versioning rigoroso

A differenza dell'implementazione semver di npm, Capgo segue rigorosamente la specifica SemVer ufficiale. Il node-semver di npm ha deviazioni note dalla specifica, che possono causare comportamenti inaspettati.

Ad esempio, npm tratta versioni come 1.0.0-alpha.1 in modo diverso da quanto richiede la specifica. Vedi il nostro problema segnalato e tentativo di fix che non è mai stato mergiato.

Versioni semantiche valide

1.0.0 ✓ Release standard

2.1.3-alpha ✓ Pre-release

1.0.0-beta.1 ✓ Pre-release con numero

1.0.0+build.1 ✓ Metadati di build

1.0.0-rc.1+build.1 ✓ Versione completa

Versioni Semantic non valide

v1.0.0 ✗ Prefisso 'v' non consentito

1.0 ✗ Versione patch mancante

1.0.0.0 ✗ Troppi elementi di versione

1.0.0- ✗ Pre-release vuota

1.0.0+ ✗ Metadati di build vuoti

Comportamento di Capgo Update

✓ La strategia Minor consente modifiche patch nella stessa linea major.minor, ad esempio 1.0.0 -> 1.0.1

✓ La strategia Patch blocca 1.0.0 -> 1.0.1. Consente solo modifiche al suffisso come 1.0.0-beta.1 -> 1.0.0-beta.2.

✗ La strategia Major blocca i bundle di destinazione con una major superiore alla baseline nativa, es. 1.0.0 -> 2.0.0

⚠ La protezione dal downgrade usa la precedenza semver completa, quindi la versione stabile 1.0.0 è più recente di 1.0.0-beta.2

Questo tool segue la specifica ufficiale Specifiche Semantic Versioning a differenza dell'implementazione di npm.