__CAPGO_KEEP_0__ Aggiornamento in tempo reale - __CAPGO_KEEP_1__ Cloud
Capgo home page

Capgo Tester di Semver

Verifica la compatibilità della politica del canale contro il baseline nativo inviato come version_build

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

Impostazioni Avanzate

Inserisci due versioni semantiche per visualizzare la comparazione

Cosa significa "Versione di baseline nativa"

La Versione di baseline 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 CapacitorUpdater.version da capacitor.config.*Se tale 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 copiassi quel valore nella configurazione o nei metadati nativi.

L'app Capgo utilizza ancora version_name sapere quale bundle scaricato è attualmente installato. major, minore patch confrontare il bundle remoto contro version_build.

Capacitor config

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

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

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

Versione app nativa

Utilizzare 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 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 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 di 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 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 nativa del negozio

Ciò impedisce che Capgo 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

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 "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
e

E' importante: 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-rilascio (-) - 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à

E' importante: 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

🏢 Impresa / Regolamentata

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

💡 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 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 o elemento di navigazione visto in: pagina trust.astro. Chiave di messaggio `e` (E). che non è mai stato integrato.

Versioni Semantic Validi

1.0.0 ✓ Rilascio standard
2.1.3-alpha ✓ Pre-rilascio
1.0.0-beta.1 ✓ Pre-rilascio con numero
1.0.0+build.1 ✓ Metadati di costruzione
1.0.0-rc.1+build.1 ✓ Versione completa

Versioni Semantic 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-rilascio 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 pacchetti 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 diversamente dall'implementazione di __CAPGO_KEEP_0__ unlike npm's implementation.