Capgo Tester di Semver

Verifica la compatibilità della politica del canale contro la linea di base nativa inviata come versione_build

Versione di Riferimento Nativa

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

Versione Remota

La versione del bundle assegnata al canale risolto.

Contesto dell'App

Piattaforma

Costruzione di sviluppo

Eseguibile su emulatore

Impostazioni del canale

Dispositivo iOS

Consenti aggiornamenti per dispositivi iOS

Dispositivo Android

Consenti aggiornamenti per dispositivi Android

Consenti costruzione di sviluppo

Consenti aggiornamenti per costruzioni di sviluppo

Consenti agli emulatori

Consenti gli aggiornamenti per i dispositivi emulatori

Disabilita l'abbassamento automatico sotto nativo

Previene l'abbassamento quando si esegue nativo code

Disabilita l'aggiornamento automatico

Maggiore: blocca la versione maggiore superiore a version_build. Consente 1.2.3 -> 1.9.0, blocca 1.2.3 -> 2.0.0.

Inserisci due versioni semantiche per visualizzare la comparazione

Cosa significa "Versione di Riferimento Nativa"

Native Baseline Version is the native app version sent to Capgo as version_build when the device asks the update server for a bundle. In a Capacitor app, that value can come from CapacitorUpdater.version . Se tale impostazione non è presente, il plugin ricade sulla versione dell'app nativa da iOS o Android. Non supporre che sia la tua capacitor.config.*versione a meno che non copiassi quel valore nella configurazione o nei metadati nativi. package.json Capgo utilizza ancora

Capgo still uses version_name Sapere quale bundle scaricato è attualmente installato. Il canale delle politiche semver come major, minor, e patch confrontare il bundle remoto contro version_build.

Capacitor configurazione

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

Pro: facile da mantenere lo stesso per le build iOS e Android.

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

Versione dell'app nativa

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

Pro: corrisponde al binario installato dagli utenti tramite TestFlight, App Store, Play Store o testing interno.

Con: modificarlo richiede una compilazione nativa e può differire da piattaforma a piattaforma se le impostazioni di rilascio si allontanano.

Target bundle

Confrontalo con le versioni remote del bundle, le regole semver del canale o le restrizioni di caricamento dei metadati come --min-update-versionIl canale deve utilizzare --disable-auto-update metadata.

Pro: prevenire l'invio di JavaScript che richiede una versione nativa code più recente per i binari di app vecchi.

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

For questo tester, inserisci la versione di base nativa che il dispositivo invia come version_build, poi confrontala con la versione del pacchetto remoto che desideri Capgo consegnare.

Perché Capgo utilizza la versione semantica

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

Il 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 minori (1.0.0 → 1.1.0): Nuove funzionalità, compatibili con il retro
Aggiornamenti maggiori (1.0.0 → 2.0.0): Cambiamenti di rotta, richiedono rilascio di app nativa negli store

Ciò impedisce che Capgo invii mai un aggiornamento incompatibile al tuo code nativo, proteggendo gli utenti da crash e garantendo che l'applicazione rimanga stabile.

Strategie Semver Flessibili: Oltre la Versioning Base

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

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

1.2.0+20240315.142530

Timestamp per il tracciamento della distribuzione

1.2.0+aggiornamento dell'interfaccia utente per il design

1.2.0+numero di costruzione del CI/CD e commit Git a1b2c3d

Ecco il punto chiave: Il metadati del build vengono ignorati nella precedenza delle versioni - 1.2.0+anything uguale 1.2.0 per la logica di aggiornamento di Capgo.

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

1.3.0-beta.1

Canale di test per versioni beta

1.3.0-hotfix.payment

Ramo di correzione urgente

1.3.0-feature.newapi

Ramo di test per nuove funzionalità

Ecco il punto chiave: Le versioni pre-release hanno una precedenza inferiore - 1.3.0-beta.1 < 1.3.0

🎯 Approccio ibrido - Migliore di entrambi i mondi

1.3.0-rc.1+ui.redesign.20240315

Candidato di rilascio con metadati di interfaccia utente e timestamp

Utilizzo reale dei casi di semver e strategie di squadra

🚀 Avvio / Sviluppo rapido

0.1.0 - Primo rilascio MVP

0.2.0-beta.1 - Test di nuove funzionalità

0.2.0+ui.v2 - Metadati di ridisegno dell'interfaccia utente

1.0.0 - Pronto per la produzione

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

🏢 Imprese / Regolamentate

2.1.0 → Rilascio trimestrale

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

2.2.0-rc.1+audit.ready → Candidato di 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 di tipo evento

1.2.0+assets.hd.remaster → Aggiornamenti di asset

Metadati creativi per il tracciamento del contenuto

⚡ Strategia di patch veloce

1.2.0 → Produzione corrente

1.2.1-hotfix.payment → Correzione critica di bug

1.2.1+urgent.20240315.1430 → Rilasciato con timestamp

Pre-release per test, metadati per la tracciatura della distribuzione

🌍 Strategia Multi-Platforma

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 → Pre-release automatizzato

1.4.0+deploy.staging.456 → Distribuzione di staging

1.4.0+prod.final.789 → Distribuzione di produzione

Versionamento automatico con metadati di distribuzione

Suggerimenti Pro:

Usa i metadati di costruzione (+) per la tracciatura, i timestamp o le informazioni estetiche che non influiscono sulla compatibilità
Usa gli identificatori di versione pre-release (-) 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 la versioning semantico 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.

Ad esempio, npm tratta le versioni come 1.0.0-alpha.1 differente rispetto a quanto richiesto dalla specifica. Vedi il nostro issue segnalato e context che non è mai stato integrato.

Versioni Semantiche 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 Validi

v1.0.0 ✗ Non è consentito il 'v' iniziale

1.0 ✗ Mancante la versione di patch

1.0.0.0 ✗ Troppi componenti di versione

1.0.0- ✗ Pre-release vuoto

1.0.0+ ✗ Metadati di costruzione vuoti

Capgo Comportamento dell'aggiornamento

✓ La strategia minore consente modifiche di patch nella stessa linea maggiore.minore, ad esempio 1.0.0 -> 1.0.1

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

✗ La strategia maggiore blocca bundle di destinazione con un maggiore maggiore della linea di base nativa, ad esempio 1.0.0 -> 2.0.0

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

Questo strumento segue la specifica di versionamento semantico ufficiale diversamente dall'implementazione di __CAPGO_KEEP_0__ unlike npm's implementation.