Capgo Testeur de Semver

Vérifiez la compatibilité de la politique de canal contre la ligne de base native envoyée sous forme de version_build

Version de la ligne de base native

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

Version distante

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

Contexte de l'application

Plateforme

Étape de Développement

Exécuté sur Émulateur

Paramètres de Canal

iOS

Autoriser les mises à jour pour les appareils iOS

Android

Autoriser les mises à jour pour les appareils Android

Autoriser l'étape de développement

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

Autoriser les émulateurs

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

Désactiver la dégradation automatique sous native

Empêche la dégradation lorsque l'on exécute nativement code

Désactiver la mise à jour automatique

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

Entrez deux versions sémantiques pour voir la comparaison

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

Native Baseline Version is the native app version sent to Capgo as version_build when the device asks the update server for a bundle. In a Capacitor app, that value can come from CapacitorUpdater.version Si ce paramètre n'est pas présent, 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 version, à moins que votre build copie cette valeur dans la configuration ou les métadonnées natives. capacitor.config.*Capgo utilise toujours package.json __CAPGO_KEEP_0__

Capgo version_name savoir quel bundle téléchargé est actuellement installé. major, minor, et patch comparer le bundle distant contre version_build.

Capacitor config

Définir CapacitorUpdater.version lorsque vous souhaitez une version explicite envoyée par l'application.

Avantages : facile à maintenir identique sur 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 à jour native.

Version de l'application native

Utiliser la version de la plateforme, par exemple iOS CFBundleShortVersionString ou Android versionName.

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

Con : la modification de ce paramètre nécessite une compilation native et peut varier en fonction du système d'exploitation si les paramètres de publication divergent.

Target de paquet

Comparez-l’avec les versions de paquets distantes, les règles de version semver du canal, ou les contraintes de métadonnées d'upload comme --min-update-versionLe canal doit utiliser --disable-auto-update metadata.

Pro : empêche l'envoi de JavaScript qui nécessite une version native code plus récente vers des binaires d'applications anciennes.

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

For ce tester, entrez la version de base native que le dispositif envoie comme version_buildEnsuite, comparez-l’avec la version de bundle distant que vous souhaitez Capgo livrer.

Pourquoi Capgo utilise-t-il la versionnement Sémantique ?

La versionnement Sémantique La versionnement Sémantique est le standard de versionnement le plus largement adopté dans le développement logiciel. En utilisant semver, Capgo assure la compatibilité et la sécurité lors de la livraison d'actualisations en direct à vos applications Capacitor.

Le standard semver permet à Capgo de comprendre exactement quelles modifications sont incluses dans chaque mise à jour :

Mises à jour de patch (1.0.0 → 1.0.1) : Corrections de bogues, sûres à appliquer automatiquement
Mises à jour mineures (1.0.0 → 1.1.0) : Nouvelles fonctionnalités, compatibles avec les versions précédentes
Mises à jour majeures (1.0.0 → 2.0.0) : Changements de rupture, nécessitant une mise à jour native de l'appareil

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

Même si semver est strict sur sa forme de base, vous pouvez l'étendre pour répondre aux besoins de votre équipe en utilisant identificateurs de pré-version et informations de métadonnées de construction:

🏷️ Informations de métadonnées de construction (+) - La couche "Cosmétique"

1.2.0+20240315.142530

Heure de déploiement pour le suivi

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 : Le métadonnées de construction sont ignorées dans l'ordre de priorité de version - 1.2.0+anything équivaut à 1.2.0 pour la logique d'actualisation de Capgo.

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

1.3.0-beta.1

Canal de test de version bêta

1.3.0-hotfix.payment

Branchement de correction urgente

1.3.0-feature.newapi

Canal de test de branche de fonctionnalité

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 de sortie avec des métadonnées d'interface utilisateur et une date de timestamp

Cas d'utilisation et stratégies de semver dans le monde réel & é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 la conception de l'interface utilisateur

1.0.0 - Prêt pour la production

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

🏢 Entreprise / Réglementée

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 de pré-audit

Strict semver 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 correctif chaud

1.2.0 → Production actuelle

1.2.1-hotfix.payment → Correction critique de bogues

1.2.1+urgent.20240315.1430 → Libéré avec horodatage

Pré-version pour les tests, métadonnées pour le suivi de déploiement

🌍 Stratégie multi-plateforme

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

🔄 Intégration CI/CD

1.4.0-alpha.1+build.123 → Pré-version automatisée

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

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

Versionnement automatique avec métadonnées de déploiement

💡 Conseils Pro:

Utilisez les métadonnées de construction (+) pour suivre, les horodatages ou les informations cosmétiques qui ne modifient pas la compatibilité
Utilisez les identificateurs 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
Rappelez-vous : Capgo respecte les règles de prééminence de semver, planifiez donc votre stratégie de canal en conséquence

Important : Capgo utilise une versionnement semantique stricte

Contrairement à l'implémentation semver de npm, Capgo suit strictement la spécification SemVer officielle. 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 diféremment que la spécification le requiert. Consultez notre incident signalé et context ce n'a jamais été fusionné.

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 ✓ Métadonnées de construction

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

1.0.0.0 ✗ Trop de parties de version

1.0.0- ✗ Pré-version vide

1.0.0+ ✗ Données de build vides

Capgo Comportement de mise à jour

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

✓ La stratégie de patch bloque 1.0.0 -> 1.0.1. Elle ne permet que des 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 de ligne native, par exemple 1.0.0 -> 2.0.0

⚠ La protection de dégradation utilise la prééminence de semver complète, 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 Cela diffère de l'implémentation de __CAPGO_KEEP_0__. unlike npm's implementation.