Capgo Tester di Semver

Verifica la compatibilità della politica del canale contro la baseline nativa inviata come versione_build

Versione Baseline Nativa

La versione nativa inviata a Capgo come versione_build, da configurazione o metadati dell'app nativa.

Versione Remota

La versione del bundle assegnata al canale risolto.

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 come version_build quando il dispositivo chiede al server di aggiornamento un pacchetto. In un'app Capacitor, quel valore può provenire da CapacitorUpdater.version in capacitor.config.*. Se tale impostazione non è presente, il plugin ricade sulla versione nativa dell'applicazione da iOS o Android. Non supporre che sia la tua package.json versione a meno che il tuo build copi quel valore in config o metadati nativi.

Capgo utilizza version_name per sapere quale bundle scaricato è attualmente installato. Le politiche di canale semver come major, minor, and patch , e version_build.

Capacitor config

__CAPGO_KEEP_0__ config CapacitorUpdater.version Set

quando desideri una versione esplicita inviata dall'applicazione. Pro:

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

Versione app nativa

Usa la versione del sistema, ad esempio iOS CFBundleShortVersionString o Android versionName.

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

Contro: modificarlo richiede un build nativo e può differire tra piattaforme 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 upload come --native-version.

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

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

Inserisci per questo tester la versione nativa di base che il dispositivo invia come version_buildpoi confrontala con la versione del pacchetto remoto 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 minori (1.0.0 → 1.1.0): Nuove funzionalità, compatibilità a ritroso
Aggiornamenti principali (1.0.0 → 2.0.0): Modifiche di rottura, richiede rilascio di app nativa sul negozio

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

Strategie Semver flessibili: oltre alla versioning base

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

🏷️ Metadati di costruzione (+) - La "Layer" Cosmetica

1.2.0+20240315.142530

Timestamp per il tracciamento dei deployment

1.2.0+ui.refresh.dark-mode

Descrizione di aggiornamento dell'interfaccia per il team di design

1.2.0+build.4729.commit.a1b2c3d

Numero di costruzione CI/CD e commit Git

Importante: La metadata di costruzione è ignorata nella precedenza di 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 test beta

1.3.0-hotfix.payment

Ramo di correzione urgente

1.3.0-feature.newapi

Test di rami feature

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

🎯 Approccio ibrido - Miglior 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

🚀 Startup / 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 UI

1.0.0 - Pronto per la produzione

Usa 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 il rilascio pre-audit

Semver rigoroso con metadati di conformità

🎮 Giochi / Applicazioni Creative

1.0.0+season.winter.2024 → Contenuto stagionale

1.1.0+event.halloween → Caratteristiche event-driven

1.2.0+assets.hd.remaster → Aggiornamenti di asset

Metadati creativi per il tracking del contenuto

⚡ Strategia di Hotfix

1.2.0 → Produzione corrente

1.2.1-hotfix.payment → Correzione critica di bug

1.2.1+urgent.20240315.1430 → Rilascio con timestamp

Pre-release per test, metadati per il tracking di deployment

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

1.4.0+deploy.staging.456 → Distribuzione di staging

1.4.0+prod.final.789 → Distribuzione di produzione

La versione automatica 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 di aggiornamento diversa
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 versione semantica rigorosa

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

Ad esempio, npm tratta versioni come 1.0.0-alpha.1 differente rispetto a quanto richiesto dalla specifica. Vedi il nostro issue segnalato e soluzione tentata che non è mai stata integrata.

Versioni Semantiche valide

1.0.0 ✓ Rilascio standard

2.1.3-alpha ✓ Prerelease

1.0.0-beta.1 ✓ Prerelease 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 ✗ 'v' iniziale non consentito

1.0 ✗ Versione patch mancante

1.0.0.0 ✗ Troppi parti della versione

1.0.0- ✗ Pre-release vuoto

1.0.0+ ✗ Metadati di build 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ù nuovo di 1.0.0-beta.2

Questo strumento segue la specifica di versionamento semantico ufficiale a differenza del __CAPGO_KEEP_0__'s implementazione. npm's implementation differs from the official Semantic Versioning specification.