Capgo Testeur 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 forme de version_build, à partir de la configuration ou des métadonnées de l'application native.

Version Distante

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

Contexte de l'Application

Plateforme

Bâtiment 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 un bâtiment de développement

Autoriser les mises à jour pour les bâtiments 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

Ce que signifie "Version Native de Base"

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 de iOS ou Android. N'assumez pas qu'il s'agit de votre capacitor.config.*version, à moins que votre build copie cette valeur dans la configuration ou les métadonnées natives. package.json Capgo utilise toujours

Capgo version_name Connaitre quelle version du bundle téléchargé est actuellement installée. major, minor, et patch Comparer le bundle distant avec version_build.

Capacitor config

Configurer CapacitorUpdater.version Lorsque vous souhaitez une version explicite envoyée par l'application.

Avantages : Facile à conserver identique sur les builds iOS et Android.

Inconvénients : Une 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

Utilisez la version de la plateforme, comme 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 l'ensemble de ressources

Comparez-l’avec les versions de l'ensemble de ressources distantes, les règles de versionnement semver du canal, ou les contraintes de téléversement de métadonnées telles que --min-update-versionLe canal doit utiliser --disable-auto-update metadata.

Pro : empêche l'envoi de JavaScript nécessitant 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 de l'ensemble de ressources soient ajustées.

For ce testeur, entrez la version de base native que le dispositif envoie comme version_buildEnsuite, comparez-l’avec la version du 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 vers 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 le mode arrière
Mises à jour majeures (1.0.0 → 2.0.0) : Changements de rupture, nécessitent une mise à jour native de l'application magasin

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

Importants : Les métadonnées de construction sont ignorées dans l'ordre de priorité des versions - 1.2.0+anything équivaut à 1.2.0 pour la logique d'actualisation de Capgo.

🔧 Identificateurs de version préalable (-) - 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

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

1.2.0 → Production actuelle

1.2.1-hotfix.payment → Correction critique d'un bug

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 à la plateforme

🔄 Intégration CI/CD

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

1.4.0+deploy.staging.456 → Déploiement de phase de test

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 construction (+) pour suivre, les horodatages ou les informations cosmétiques qui ne modifient pas la compatibilité
Utilisez les identifiants de version préliminaire (-) 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 priorité de version semver, planifiez donc votre stratégie de canal en conséquence

Important : Capgo utilise une versionnement semantique stricte

À la différence de 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 differemment que la spécification le requiert. Consultez notre incident signalé et context : Page/zone : Site web de marketing Capgo. Rôle : Étiquette de navigation ou élément UI court. Vu dans : page trust.astro. Clé de message `et` (Et). 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éta-données de build

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+ ✗ Les métadonnées de construction sont vides

Capgo Comportement de mise à jour

✓ La stratégie mineure permet les modifications de patch dans la même ligne majeure mineure, 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 stable 1.0.0 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.