Capgo Tester Semver

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

Versione di base nativa

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

Versione remota

La versione del pacchetto assegnata al canale risolto.

Context dell'app

Piattaforma

Versione di sviluppo

Esecuzione su Emulatore

Impostazioni del Canale

iOS

Consenti aggiornamenti per dispositivi iOS

Android

Consenti aggiornamenti per dispositivi Android

Consenti costruzione di build di sviluppo

Consenti aggiornamenti per build di sviluppo di sviluppo

Consenti Emulatore

Consenti aggiornamenti per dispositivi emulatori

Disabilita downgrade automatico sotto nativo

Previene il downgrade quando si esegue nativo code

Disabilita l'aggiornamento automatico

Maggiore: blocca la versione target maggiore di quella di build. Consente 1.2.3 -> 1.9.0, blocca 1.2.3 -> 2.0.0.

Inserisci due versioni semantiche per visualizzare la comparazione

Cos'è la "Versione di Baseline Nativa"

La Versione di Baseline Nativa è la versione dell'app nativa inviata a Capgo quando version_build quando il dispositivo chiede al server di aggiornamento un bundle. In un'app Capacitor, quel valore può provenire da CapacitorUpdater.version da capacitor.config.*Se quella impostazione 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 copi quel valore nella configurazione o nei metadati nativi.

Capgo utilizza ancora version_name per sapere quale bundle scaricato è attualmente installato. Le politiche semver del canale, come major, minor, e patch confronta il bundle remoto contro version_build.

Capacitor configurazione

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

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

Con: 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 degli utenti installato da TestFlight, App Store, Play Store o test interni.

Contro: modificarlo richiede una compilazione nativa e può differire a seconda della piattaforma se i parametri di rilascio si allontanano.

Target bundle

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 una versione nativa code più recente per binari di app vecchi.

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 il baseline nativo che il dispositivo invia come version_builde confrontalo con la versione del bundle 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_KEEP_0__ garantisce compatibilità e sicurezza quando si inviano aggiornamenti live ai propri __CAPGO_KEEP_1__ app. is the most widely adopted versioning standard in software development. By using semver, Capgo ensures compatibility and safety when delivering live updates to your Capacitor apps.

The semver standard allows Capgo to understand exactly what changes are included in each update:

Correzioni di bug, sicure per l'applicazione automatica Aggiornamenti minori (1.0.0 → 1.1.0):
Nuove funzionalità, compatibili con il passato Aggiornamenti maggiori (1.0.0 → 2.0.0):
Cambiamenti dirompenti, richiedono rilascio di app nativa negli store Ciò impedisce a __CAPGO_KEEP_0__ di inviare mai un aggiornamento incompatibile al proprio __CAPGO_KEEP_1__ nativo, proteggendo gli utenti da crash e assicurando che l'app rimanga stabile.

This prevents Capgo from ever sending an incompatible update to your native code, protecting your users from crashes and ensuring your app remains stable.

Mentre semver è rigoroso sul suo formato di base, puoi estenderlo per le esigenze del tuo team utilizzando

__CAPGO_KEEP_0__ identificatori di versione pre-rilascio e Metadati di costruzione:

🏷️ Metadati di costruzione (+) - La "Cappa" di Decorazione

1.2.0+20240315.142530

Timestamp per il tracciamento delle distribuzioni

1.2.0+aggiornamento della UI in modalità oscurità

Descrizione dell'aggiornamento della UI per il team di design

1.2.0+build.4729.commit.a1b2c3d

Numero di costruzione e commit Git del CI/CD

Importante: I metadati di costruzione sono ignorati nella precedenza delle versioni - 1.2.0+anything uguale 1.2.0 per la logica di aggiornamento di Capgo.

🔧 Identificatori di pre-rilascio (-) - 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

Ramo di test per nuove funzionalità

Nota: Le versioni di pre-rilascio 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

Casi di utilizzo Semver nel mondo reale & strategie di squadra

🚀 Sviluppo rapido / Startup

0.1.0 - Primo rilascio MVP

0.2.0-beta.1 - Test di nuova funzionalità

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

1.0.0 - Rilascio 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

Strict semver con metadati di conformità

Giochi e App creativi 🎮

1.0.0+season.winter.2024 → Contenuto stagionale

1.1.0+event.halloween → Caratteristiche basate su eventi

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 → Rilasciato con timestamp

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

🌍 Strategia Multi-Platform

1.3.0+ios.optimized → Ottimizzazioni specifiche per iOS

1.3.0+android.material3 → Aggiornamenti di design per Android

1.3.0+web.pwa.ready → Funzionalità di 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

1.4.0+prod.final.789 → Distribuzione di produzione

Versione automatica con metadati di distribuzione

💡 Pro Consigli:

Utilizza i metadati di build (+) per la tracciatura, i timestamp o le informazioni estetiche che non influiscono sulla compatibilità
Utilizza 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 la versione semantica rigorosa

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

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

Versioni Semantiche Validi

1.0.0 ✓ Rilascio standard

2.1.3-alpha ✓ Prima della versione di rilascio

1.0.0-beta.1 ✓ Prima della versione di rilascio 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 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

✓ Estrategia 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.

✗ Estrategia di patch principale mira pacchetti con un maggior numero maggiore della 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 diversamente dall'implementazione di __CAPGO_KEEP_0__. unlike npm's implementation.