Capgo Verificatore di Semver

Verifica la compatibilità della versione semantica per le tue Capacitor aggiornamenti dell'app

Versione Locale

La versione che il tuo app installato segnala a Capgo, dal config o dai metadati dell'app nativa.

Versione Remota

Inserisci due versioni semantiche per visualizzare la comparazione

Cosa significa "Versione Locale"

La Versione Locale è la versione già presente sul dispositivo quando richiede al server di aggiornamento un pacchetto. In un'app Capacitor, quel valore può provenire da CapacitorUpdater.version in capacitor.config.*. Se quel setting non è presente, il plugin ricade sulla versione nativa dell'app di iOS o Android. Non assumere che sia la tua package.json versione a meno che non copi quel valore nella configurazione o nei metadati nativi.

Configurazione Capacitor

Imposta CapacitorUpdater.version quando desideri una versione esplicita inviata dall'applicazione.

Pro: facile da mantenere identico tra le build iOS e Android.

Con: una configurazione datata può riportare la versione sbagliata se dimentichi di aggiornarla prima di una rilascio nativo.

Versione dell'applicazione nativa

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

Pro: corrisponde alla versione binaria installata dai utenti da TestFlight, App Store, Play Store o test interni.

Con: modificarlo richiede una build nativa e può differire tra piattaforme se le impostazioni di rilascio si allontanano.

Bundle di destinazione

Confrontalo con le versioni remote del bundle, le regole semver del canale o le restrizioni di caricamento come --native-version.

Pro: prevenire l'invio di JavaScript che richiede nativi più recenti code per vecchie versioni dell'applicazione.

Contro: le regole troppo restrittive possono bloccare aggiornamenti validi fino a quando il canale o i metadati del bundle non vengono aggiustati.

Per questo tester, inserisci la versione che il dispositivo riporterebbe come locale, quindi confrontala con la versione remota del bundle che desideri Capgo inviare.

Perché Capgo utilizza la versione semantica

La versione semantica è lo standard di versioning più ampiamente adottato nello sviluppo software. Utilizzando semver, Capgo garantisce compatibilità e sicurezza quando si inviano aggiornamenti live alle tue Capacitor applicazioni.

Lo standard semver consente a Capgo di comprendere esattamente quali modifiche sono incluse in ogni aggiornamento:

Aggiornamenti di patch (1.0.0 → 1.0.1): Correzioni di bug, sicure per l'applicazione automatica
Aggiornamenti minimi (1.0.0 → 1.1.0): Nuove funzionalità, compatibili con il passato
Aggiornamenti maggiori (1.0.0 → 2.0.0): Cambiamenti di compatibilità, richiedono rilascio di app nativa sullo store

Ciò impedisce a Capgo di inviare mai un aggiornamento incompatibile al tuo code, proteggendo i tuoi utenti da crash e assicurando che l'app rimanga stabile.

Strategie Semver Flessibili: Oltre la Versioning Base

Sebbene semver sia rigoroso sul suo formato base, puoi estenderlo per le esigenze del tuo team utilizzando identificatori di pre-release e metadati di costruzione:

🏷️ Metadati di Costruzione (+) - La 'Lamina Cosmetica'

1.2.0+20240315.142530

Timestamp per la tracciatura della distribuzione

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 commit Git

Importante: I metadati di costruzione vengono ignorati nella precedenza della versione - 1.2.0+anything uguale 1.2.0 per Capgo's logica di aggiornamento.

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

1.3.0-beta.1

Canale di testing beta

1.3.0-hotfix.payment

Ramo di correzione urgente

1.3.0-feature.newapi

Ramo di testing per nuove API

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

Approccio ibrido - Migliori di entrambi i mondi

1.3.0-rc.1+ui.redesign.20240315

Candidato di rilascio con metadati UI e timestamp

Casi d'uso Semver nel mondo reale & strategie di squadra

🚀 Sviluppo rapido / Startup

0.1.0 - Primo rilascio MVP

0.2.0-beta.1 - Nuova funzione di testing

0.2.0+ui.v2 - Ri-design dell'interfaccia utente per metadati

1.0.0 - Pronto per la produzione

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

🏢 Imprese / Regolamentate

2.1.0 → Rilascio trimestrale

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

2.2.0-rc.1+audit.ready → Candidato per la rilascio pre-audit

Semver rigoroso con metadati di conformità

🎮 Applicazioni di gioco / Creative

1.0.0+season.winter.2024 → Contenuto stagionale

1.1.0+event.halloween → Caratteristiche guidate dagli eventi

1.2.0+assets.hd.remaster → Aggiornamenti di asset

Metadati creativi per il tracciamento dei contenuti

⚡ Strategia di Hotfix

1.2.0 → Produzione corrente

1.2.1-hotfix.payment → Correzione critica di bug

1.2.1+urgent.20240315.1430 → Rilasciato con timestamp

Pre-rilascio per test, metadati per il tracciamento della distribuzione

🌍 Strategia Multi-Platform

1.3.0+ios.optimized → Ottimizzazioni iOS specifiche

1.3.0+android.material3 → Aggiornamenti di design Android

1.3.0+web.pwa.ready → Capacità PWA

Stessa versione, metadati specifici per piattaforma

Integrazione CI/CD

1.4.0-alpha.1+build.123 → Distribuzione pre-rilascio automatizzata

1.4.0+deploy.staging.456 → Distribuzione di staging automatizzata

1.4.0+prod.final.789 → Distribuzione di produzione automatizzata

Versione automatica con metadati di distribuzione

💡 Progetti:

Usa i metadati di costruzione (+) per la tracciatura, i timestamp o le informazioni estetiche che non influiscono sulla compatibilità
Usa gli identificatori di pre-rilascio (-) per i canali di sviluppo che richiedono una precedenza diversa degli aggiornamenti
Combina entrambi per massima flessibilità: 1.2.0-beta.1+ui.dark.theme.20240315
Ricorda: Capgo rispetta le regole di precedenza semver, quindi pianifica la tua strategia di canale di conseguenza

Importante: Capgo utilizza una versione semantica rigorosa

A differenza dell'implementazione semver di npm, Capgo segue la specifica SemVer ufficiale in modo rigoroso. npm's node-semver ha delle deviazioni note dalla spec, che possono causare un comportamento imprevisto.

Per esempio, npm tratta le versioni come 1.0.0-alpha.1 in modo diverso rispetto a quanto richiesto dalla specifica. Vedi il nostro issue segnalato e tentativo di risoluzione che non è mai stato integrato.

Versioni Semanticamente Validi

1.0.0 ✓ Rilascio standard

2.1.3-alpha ✓ Pre-release

1.0.0-beta.1 ✓ Pre-release con numero

1.0.0+build.1 ✓ Metadati di costruzione

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

Versioni semantiche non valide

v1.0.0 ✗ Non è consentito il 'v' in testa

1.0 ✗ Mancanza di versione di patch

1.0.0.0 ✗ Troppi componenti di versione

1.0.0- ✗ Pre-release vuoto

1.0.0+ ✗ Metadati di build vuoti

Capgo Comportamento dell'aggiornamento

✓ Gli aggiornamenti di patch vengono applicati automaticamente (1.0.0 → 1.0.1)

✓ Gli aggiornamenti minori richiedono la configurazione del canale (1.0.0 → 1.1.0)

✗ Gli aggiornamenti maggiori richiedono la pubblicazione dell'app nativa nel negozio (1.0.0 → 2.0.0)

⚠ Le versioni pre-release richiedono una configurazione esplicita

Questo strumento segue le linee guida ufficiali Specificazione di versione semantica a differenza dell'implementazione di npm.