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 pacchetto assegnata al canale risolto.

Contesto dell'app

Piattaforma

Costruzione di sviluppo

Eseguibile su emulatore

Impostazioni del canale

iOS

Consenti aggiornamenti per dispositivi iOS

Android

Consenti aggiornamenti per dispositivi Android

Consenti costruzione di sviluppo

Consenti aggiornamenti per costruzioni di sviluppo

Consenti emulatori

Consenti aggiornamenti per dispositivi emulatori

Disabilita downgrade automatico sotto nativo

Impedisce il downgrade quando si esegue il codice code

Disabilita l'aggiornamento automatico

Maggiore: blocca la versione target maggiore maggiore di 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.*. If that setting is not present, the plugin falls back to the native app version from iOS or Android. Do not assume it is your package.json version 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. Le politiche semver del canale, come major, minor, e patch per confrontare il bundle remoto contro version_build.

. Capacitor config

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

Pro: facile mantenere la stessa versione su build 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 alla versione binaria installata dai utenti da TestFlight, App Store, Play Store o testing interno.

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

Target bundle

Confronta con versioni remote del bundle, regole semver del canale o vincoli di caricamento dei metadati come --min-update-versionLa canale deve utilizzare --disable-auto-update metadata.

Pro: evita di inviare JavaScript che richiede una versione nativa più recente di code a binari di app vecchi.

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

Per questo tester, inserisci la linea di base nativa che il dispositivo invia come version_builde 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 invia aggiornamenti live alle tue 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à, compatibilità con il passato
Aggiornamenti principali (1.0.0 → 2.0.0): Modifiche di base, richiedono rilascio nativo dell'app

Questa prevenzione garantisce che Capgo non invii 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

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

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

1.2.0+20240315.142530

Timestamp per il tracciamento delle deployment

Timestamp per la tracciatura dei deployment

UI update description for design team

1.2.0+build.4729.commit.a1b2c3d

Numero di costruzione CI/CD e commit Git

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

🔧 Identificatori di versione pre-release (-) - 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 di feature

Nota: 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 dei casi d'uso semver reali & strategie di squadra

🚀 Avvio rapido / Sviluppo veloce

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

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à

🎮 Giochi / Applicazioni 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 tracking del contenuto

⚡ Strategia di Hotfix

1.2.0 → Versione corrente in produzione

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 per Android

1.3.0+web.pwa.ready → Capacità di PWA

Versione identica, 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

💡 Progetti Pro:

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

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

Ad esempio, npm tratta le versioni come 1.0.0-alpha.1 differente rispetto a quanto richiesto dalla specifica. Vedi il nostro Rapporto problema e Risposta non integrata Versioni semantiche valide

✓ Rilascio standard

1.0.0 ✓ Rilascio standard

2.1.3-alpha ✓ Pre-release

1.0.0-beta.1 ✓ Metadati di costruzione

1.0.0+build.1 ✓ Versione completa

1.0.0-rc.1+build.1 Versioni semantiche non valide

✗ 'v' in testa non consentito

v1.0.0 tentativo di correzione

1.0 ✗ Manca la versione patch

1.0.0.0 ✗ Troppi elementi di versione

1.0.0- ✗ Versione pre-release vuota

1.0.0+ ✗ Metadati di costruzione vuoti

Capgo Comportamento dell'aggiornamento

✓ La strategia minore consente modifiche di patch nella stessa riga 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 le linee guida ufficiali Specificazione di versionamento semantico rispetto all'implementazione di npm.