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 pacchetto 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 gli emulatori

Consenti gli aggiornamenti per dispositivi emulatori

Disabilita la discesa automatica sotto nativo

Previene la discesa quando si esegue nativo code

Disabilita l'aggiornamento automatico

Maggiore: blocca la versione maggiore superiore a versione_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"

La Versione di Riferimento Nativa è la versione dell'app nativa inviata a Capgo quando version_build il dispositivo chiede al server di aggiornamento un bundle. In un'app Capacitor, quel valore può provenire da CapacitorUpdater.version in capacitor.config.*Se quel setting non è presente, il plugin ricade sulla versione dell'app nativa da iOS o Android. Non assumere che sia la tua package.json versione a meno che non copiassi quel valore nella configurazione o nei metadati nativi.

Capgo utilizza ancora version_name per sapere quale bundle scaricato è attualmente installato. major, minor, e patch confrontare il bundle remoto contro version_build.

Capacitor config

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

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

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

Versione nativa dell'applicazione

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

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

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

Target bundle

Confrontalo con le versioni remote dei 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 delle app vecchie.

Con: le regole troppo restrittive possono bloccare gli aggiornamenti validi fino a quando i metadati del canale o 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 compatibilità e sicurezza quando si consegnano aggiornamenti live ai tuoi Capacitor app.

Il standard semver consente a Capgo di capire 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 store nativo

Ciò impedisce a Capgo di inviare mai un aggiornamento incompatibile al tuo code nativo, proteggendo gli utenti da crash e assicurando che l'app 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 metadata di costruzione:

🏷️ Metadata di Costruzione (+) - La "Layer Cosmetica"

1.2.0+20240315.142530

Timestamp per la tracciatura della distribuzione

1.2.0+aggiornamento della UI per il design team

1.2.0+build.4729.commit.a1b2c3d

numero di build CI/CD e commit Git

Ecco il punto chiave: Il metadati di costruzione 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 / creatività

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 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 il tracciamento della distribuzione

🌍 Strategia Multi-Platforma

1.3.0+ios.optimized → Ottimizzazioni iOS specifiche

1.3.0+android.material3 → Aggiornamenti di design per 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

Automazione della versione con metadati di distribuzione

💡 Pro Voti:

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-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 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 reportato problema e context: Pagina/Area: Sito web di marketing Capgo. Ruolo: Etichetta breve UI o elemento di navigazione. Visto in: pagina trust.astro. Chiave di messaggio `e` (E). 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 Valide

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

1.0 ✗ Mancante la versione di patch

1.0.0.0 ✗ Troppi componenti della 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 diversa dall'implementazione di __CAPGO_KEEP_0__ unlike npm's implementation.