Capgo Tester de Semver

Vérifiez la compatibilité de la politique de canal par rapport à la base native envoyée sous forme de version_build

Version de base native

La version native envoyée à Capgo sous la forme de version_build, à partir de la configuration ou des métadonnées de l'application native.

Version distante

La version du bundle attribuée au canal résolu.

Contexte de l'application

Plateforme

Version de développement

Exécuté sur émulateur

Réglages du canal

iOS

Autoriser les mises à jour pour les appareils iOS

Android

Autoriser les mises à jour pour les appareils Android

Autoriser la construction de développement

Autoriser les mises à jour pour les constructions de développement

Autoriser les émulateurs

Autoriser les mises à jour pour les appareils émulés

Empêcher la mise à niveau automatique sous native

Empêche la mise à niveau vers une version inférieure lors de l'exécution native code

Désactiver la mise à jour automatique

Majeur : bloque la mise à niveau vers une version majeure supérieure à la version_build. Permet 1.2.3 -> 1.9.0, bloque 1.2.3 -> 2.0.0.

Entrez deux versions semantiques pour voir la comparaison

Qu'est-ce que la "Version de base native" signifie

La Version de base native est la version de l'application native envoyée à Capgo lorsque version_build lorsque le dispositif demande au serveur d'actualisation d'un paquet. Dans une application Capacitor, cette valeur peut provenir de CapacitorUpdater.version en capacitor.config.*. Si cette configuration n'est pas présente, le plugin se réfère à la version de l'application native provenant d'iOS ou d'Android. N'assumez pas qu'il s'agit de votre package.json version à moins que votre build copie cette valeur dans la configuration ou les métadonnées natives.

Capgo utilise toujours version_name pour savoir quel paquet téléchargé est actuellement installé. Les politiques de version semantique de canal, telles que major, minor, et patch comparent le paquet téléchargé contre version_build.

la configuration de Capacitor

Configurez-le lorsque vous souhaitez une version explicite envoyée par l'application. CapacitorUpdater.version Avantages : facile à conserver identique pour les builds iOS et Android.

Inconvénients : la configuration obsolète peut signaler la mauvaise version si vous oubliez de la mettre à jour avant une mise en production native. Version de l'application native

Utilisez la version de la plateforme, comme iOS ou Android

Avantages : correspond à la version binaire que les utilisateurs ont installée à partir de TestFlight, App Store, Play Store ou de tests internes.

Inconvénients : CFBundleShortVersionString __CAPGO_KEEP_0__ versionName.

__CAPGO_KEEP_0__ __CAPGO_KEEP_0__

__CAPGO_KEEP_0__ change cela nécessite une construction native et peut différer par plateforme si les paramètres de publication dérivent.

Bundle ciblant

Comparez-le avec les versions de bundles distantes, les règles de semver du canal, ou les contraintes d'upload telles que --native-version.

Pro: empêche d'envoyer du JavaScript qui nécessite des code natives plus récents vers des binaires d'applications anciennes.

Con: les règles qui sont trop strictes peuvent bloquer des mises à jour valides jusqu'à ce que les métadonnées du canal ou du bundle soient ajustés.

Pour ce testeur, entrez la base native que le dispositif envoie comme version_build, puis comparez-le avec la version de bundle distante que vous souhaitez Capgo livrer.

Pourquoi Capgo utilise la versionnement Sémantique

Versionnement Sémantique est le standard de versionnement le plus largement adopté dans le développement logiciel. En utilisant semver, Capgo garantit la compatibilité et la sécurité lors du déploiement de mises à jour en direct vers vos Capacitor applications.

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

Les mises à jour de patch (1.0.0 → 1.0.1) : Corrections de bogues, sécurisées pour une application automatique
Les mises à jour mineures (1.0.0 → 1.1.0) : Nouvelles fonctionnalités, compatibles avec les versions précédentes
Les mises à jour majeures (1.0.0 → 2.0.0) : Les changements de rupture, nécessitent une mise à jour native de l'application

Cela empêche Capgo de jamais envoyer une mise à jour incompatible à votre native code, protégeant vos utilisateurs des plantages et garantissant que votre application reste stable.

Stratégies de Semver flexibles : au-delà de la versionnement de base

Alors que Semver est strict sur sa forme de base, vous pouvez l'étendre pour répondre aux besoins de votre équipe en utilisant les identificateurs de pré-version et build metadata:

🏷️ Informations de construction (+) - Le "Cosmétique" Layer

1.2.0+20240315.142530

Timestamp pour le suivi de déploiement

1.2.0+ui.refresh.dark-mode

Description de mise à jour de l'interface pour l'équipe de design

1.2.0+build.4729.commit.a1b2c3d

Numéro de build CI/CD et commit Git

Important : Les informations de construction sont ignorées dans la priorité de version - 1.2.0+anything équivaut à 1.2.0 pour Capgo's logique de mise à jour.

🔧 Identificateurs de pré-version (-) - Canaux de développement

1.3.0-beta.1

Canal de test beta

1.3.0-hotfix.payment

Branch de correction urgente

1.3.0-feature.newapi

Branch de test de nouvelle API

Note: Les versions préalables ont une priorité inférieure - 1.3.0-beta.1 < 1.3.0

🎯 Approche hybride - Meilleur des deux mondes

1.3.0-rc.1+ui.redesign.20240315

Candidate de version avec métadonnées d'interface utilisateur et timestamp

Cas d'utilisation Semver du monde réel et stratégies d'équipe

🚀 Développement Rapide / Lancement de Startup

0.1.0 - Première version MVP

0.2.0-beta.1 - Test de nouvelle fonctionnalité

0.2.0+ui.v2 - Métadonnées de refonte de l'interface utilisateur

1.0.0 - Prêt pour la production

Utilisez 0.x.x pour le développement pré-1.0, métadonnées pour le suivi de la conception

🏢 Entreprise / Réglementé

2.1.0 → Sortie trimestrielle

2.1.1+sec.patch.cve2024 → Correctif de sécurité avec suivi

2.2.0-rc.1+audit.ready → Candidat à la version pré-audit

Semver strict avec métadonnées de conformité

🎮 Jeux / Applications Créatives

1.0.0+season.winter.2024 → Contenu saisonnier

1.1.0+event.halloween → Fonctionnalités déclenchées par des événements

1.2.0+assets.hd.remaster → Mises à jour d'actifs

Métadonnées créatives pour le suivi du contenu

⚡ Stratégie de mise à jour de correctifs rapides

1.2.0 → Production actuelle

1.2.1-hotfix.payment → Correction critique de bogues

1.2.1+urgent.20240315.1430 → Déploiement avec horodatage

Pré-version pour les tests, métadonnées pour le suivi de la mise en production

🌍 Stratégie de multi-plateformes

1.3.0+ios.optimized → Optimisations iOS spécifiques

1.3.0+android.material3 → Mises à jour de conception Android

1.3.0+web.pwa.ready → Capacités PWA

Même version, métadonnées spécifiques à la plateforme

🔄 Intégration CI/CD

1.4.0-alpha.1+build.123 → Déploiement préalable automatique

1.4.0+deploy.staging.456 → Déploiement de stade

1.4.0+prod.final.789 → Déploiement de production

Numérotation automatique avec métadonnées de déploiement

💡 Conseils Pro:

Utilisez les métadonnées de build (+) pour suivre, les horodatages ou les informations cosmétiques qui ne modifient pas la compatibilité
Utilisez les identifiants de version préalable (-) pour les canaux de développement qui nécessitent une priorité d'actualisation différente
Combinez les deux pour une flexibilité maximale: 1.2.0-beta.1+ui.dark.theme.20240315
N'oubliez pas : Capgo respecte les règles de numérotation semver, planifiez donc votre stratégie de canal en conséquence

Important : Capgo utilise une versionnement sémantique stricte

Par contre, l'implémentation de npm du versionnement sémantique n'est pas conforme à la spécification officielle de SemVer, contrairement à Capgo qui suit strictement la spécification. npm's node-semver a des déviations connues de la spécification, ce qui peut entraîner un comportement inattendu.

Par exemple, npm traite les versions comme 1.0.0-alpha.1 differemment que la spécification ne le requiert pas. Voir notre problème signalé et tentative de correction qui n'a jamais été fusionnée.

Versions Sémantiques Valides

1.0.0 ✓ Sortie standard

2.1.3-alpha ✓ Pré-version

1.0.0-beta.1 ✓ Pré-version avec numéro

1.0.0+build.1 ✓ Construction de métadonnées

1.0.0-rc.1+build.1 ✓ Version complète

Versions sémantiques non valides

v1.0.0 ✗ 'v' en tête non autorisé

1.0 ✗ Version de correctif manquante

1.0.0.0 ✗ Trop de parties de version

1.0.0- ✗ Pré-version vide

1.0.0+ ✗ Métadonnées de construction vides

Capgo Comportement de mise à jour

✓ La stratégie mineure permet les modifications de correctif dans la même ligne majeure mineure, par exemple 1.0.0 -> 1.0.1

✓ La stratégie de correctif bloque 1.0.0 -> 1.0.1. Elle n'autorise que les modifications de suffixe comme 1.0.0-beta.1 -> 1.0.0-beta.2.

✗ La stratégie majeure bloque les ensembles de fichiers cibles avec un majeur supérieur à la base native, par exemple 1.0.0 -> 2.0.0

⚠ La protection de downgrade utilise la préférence totale de semver, donc 1.0.0 stable est plus récent que 1.0.0-beta.2

Cette outil suit la spécification de versionnement sémantique officielle contrairement à l'implémentation de __CAPGO_KEEP_0__ unlike npm's implementation.