Capgo Testeur de Semver

Vérifiez la compatibilité de la politique de canal contre 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 du paquet attribuée au canal résolu.

Entrez deux versions semantiques pour voir la comparaison

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

La Version native de base 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 de CapacitorUpdater.version In cas où ce paramètre n'est pas présent, le plugin se réfère à la version native de l'application iOS ou Android. N'assumez pas que c'est votre version, à moins que votre build copie cette valeur dans la configuration ou les métadonnées natives. __CAPGO_KEEP_0__ utilise toujours pour savoir quel bundle téléchargé est actuellement installé. Les politiques de canal semver comme ", et ", permettent de comparer le bundle distant contre __CAPGO_KEEP_0__ config Définir lorsque vous souhaitez envoyer une version explicite par l'application. Pro : facile à conserver identique dans les builds iOS et Android. capacitor.config.*. Si ce paramètre n'est pas présent, le plugin se réfère à la version native de l'application iOS ou Android. N'assumez pas que c'est votre version, à moins que votre build copie cette valeur dans la configuration ou les métadonnées natives. package.json version

Capgo still uses version_name __CAPGO_KEEP_0__ major, minorpour savoir quel bundle téléchargé est actuellement installé. patch Channel semver version_build.

Capacitor config

contre CapacitorUpdater.version __CAPGO_KEEP_0__ config

Définir quand vous souhaitez envoyer une version explicite par l'application.

Con: une configuration obsolète peut signaler la mauvaise version si vous oubliez de l'actualiser avant une mise en production native.

Version de l'application native

Utilisez la version de la plateforme, comme iOS CFBundleShortVersionString ou Android versionName.

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

Con: la modification nécessite une compilation native et peut différer par plateforme si les paramètres de mise en production divergent.

Ciblage du paquet

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

Pro: empêche l'envoi de JavaScript qui nécessite des code natifs plus récents vers les 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.

Pour ce testeur, entrez la base native que le dispositif envoie comme version_buildpuis comparez-la avec la version de paquet distant que vous souhaitez Capgo livrer.

Pourquoi Capgo utilise la versionnement Sémantique

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 du déploiement de mises à jour 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) : Nouveautés, compatible avec la version précédente
Mises à jour majeures (1.0.0 → 2.0.0) : Changements majeurs, nécessite une mise à jour de l'app native dans les magasins d'applications

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 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 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 build sont ignorées dans la priorité de version - 1.2.0+anything équivaut à 1.2.0 pour Capgo's logique de mise à jour.

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

Test de branch de fonctionnalité

Remarque : 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 horodatage

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

Lancement rapide / Développement rapide

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 redécoration d'interface utilisateur

1.0.0 - Prêt pour la production

Utilisez 0.x.x pour le développement pré-1.0, les 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 à la mise en audit préalable

Semver stricte avec des 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 correction urgente

1.2.0 → Production actuelle

1.2.1-hotfix.payment → Correction critique de bug

1.2.1+urgent.20240315.1430 → Déploiement avec horodatage

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

🌍 Stratégie de 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 stade

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 pré-version (-) pour les canaux de développement qui nécessitent une priorité différente des mises à jour
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 versionnement semver, donc planifiez votre stratégie de canal en conséquence

Important : Capgo utilise un versionnement semantique strict

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

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

Versions Sémantiques Invalides

v1.0.0 ✗ 'v' en début 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+ ✗ Informations de build vide

Capgo Comportement de mise à jour

✓ La stratégie mineure permet les modifications de version 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 paquets cibles avec un majeur supérieur à la base native, par exemple 1.0.0 -> 2.0.0

⚠ La protection de dégradation utilise la priorité 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__. npm Update Behavior