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 la 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 de bundle attribuée au canal résolu.

Contexte de l'Application

Plateforme

Construction de l'éditeur

Exécution sur émulateur

Paramètres de canal

iOS

Autoriser les mises à jour pour les appareils iOS

Développement 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

Désactiver la mise à niveau automatique sous native

Empêche la mise à niveau en basse version lors de l'exécution native code

Désactiver la mise à jour automatique

Majeur : bloque la mise à jour majeure vers une version_build supérieure. 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 comme version_build lorsque le dispositif demande au serveur d'actualisation un bundle. Dans une application Capacitor, cette valeur peut provenir CapacitorUpdater.version de capacitor.config.*. Si ce paramètre n'est pas package.json présent, le plugin recule sur la version de l'application native provenant d'iOS ou d'Android. N'assumez pas qu'il s'agit de

votre version sauf si votre build copie cette valeur dans la configuration ou les métadonnées natives. Capgo utilise toujours version_name savoir quel bundle téléchargé est actuellement installé. Politiques de canal semver telles que major, minoret 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 à conserver identique sur les builds iOS et Android.

Inconvénients : une config obsolète peut signaler la mauvaise version si vous oubliez de l'actualiser avant une mise à jour native.

Version de l'application native

Utiliser la version de la plateforme, telle que iOS CFBundleShortVersionString ou Android versionName.

Avantages : correspond à la version binaire que les utilisateurs ont installée à partir de TestFlight, de l'App Store, de Google Play, ou de la mise en test interne.

Inconvénients : la modification nécessite une compilation native et peut différer d'une plateforme à l'autre si les paramètres de publication varient.

Ciblage de l'ensemble

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

Avantages : empêche d'envoyer du JavaScript qui nécessite des code natifs plus récents que les anciens binaires d'applications.

Inconvénients : les règles trop strictes peuvent bloquer les mises à jour valides jusqu'à ce que le canal ou les métadonnées de l'ensemble soient ajustés.

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

Pourquoi Capgo utilise la versionnement Sémantique

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

La norme 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'appareil

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

Stratégies Semver Flexibles : Au-delà de la Versionnement Basique

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 méta-données de construction:

🏷️ Méta-donné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 : Les métadonnées de construction sont ignorées dans la 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

Chaîne de test de version bêta

1.3.0-hotfix.payment

Branchement de correction urgente

1.3.0-feature.newapi

Chaîne de test de branche de fonctionnalité

Note : Les versions de pré-version 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 date de timestamp

Cas d'utilisation de Semver dans le monde réel et stratégies d'équipe

🚀 Développement rapide / Lancement de startup

0.1.0 - Première version minimale viable (MVP)

0.2.0-beta.1 - Test de nouvelles fonctionnalités

0.2.0+ui.v2 - Métadonnées de la conception d'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ée

2.1.0 → Lancement trimestriel

2.1.1+sec.patch.cve2024 → Mise à jour de sécurité avec suivi

2.2.0-rc.1+audit.ready → Candidat de pré-audit

Semver strict avec métadonnées de conformité

🎮 Applications de jeux / 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 correction urgente

1.2.0 → Production actuelle

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

1.2.1+urgent.20240315.1430 → Publié avec horodatage

Version préalable 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 → Déploiement préalable automatique

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

1.4.0+prod.final.789 Déploiement automatique avec métadonnées

💡 Conseils Pro :

__CAPGO_KEEP_0__

Utilisez les métadonnées de construction (+) pour le suivi, 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 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 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 ✓ Métadonné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+ ✗ Métadonnées de build vides

Mise à jour de Capgo

✓ 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 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 priorité totale de semver, 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 contrairement à l'implémentation de __CAPGO_KEEP_0__ unlike npm's implementation.