Passer au contenu principal

Capgo Testeur de version de semver

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

The native version sent to Capgo as version_build, from config or native app metadata.

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

Entrez deux versions sémantiques pour voir la comparaison

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

La version native de base est la version de l'application native envoyée à Capgo version_build lorsque le dispositif demande au serveur de mise à jour un bundle. Dans une application Capacitor, cette valeur peut provenir de CapacitorUpdater.version en capacitor.config.*. If that setting is not present, the plugin falls back to the native app version from iOS or Android. Do not assume it is your package.json 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é. Les politiques de canal semver comme major, minor, and patch comparez le bundle distant à version_build.

Capacitor configuration

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

Pro: . Lorsque vous souhaitez une version explicite envoyée 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.

Avantages : correspond à la version binaire installée par les utilisateurs à 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-l’avec les versions de bundle distantes, les règles de semver du canal ou les contraintes d'upload de métadonnées telles que --min-update-versionLe canal doit utiliser --disable-auto-update metadata.

Avantages : prevents sending JavaScript that needs newer native code to old app binaries.

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

Pour ce testeur, entrez la base native que le dispositif envoie comme version_buildpuis comparez-l’avec la version de bundle distante que vous souhaitez que Capgo délivre.

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 de la livraison de mises à jour en direct vers vos Capacitor applications.

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) : New features, backward compatible
  • Mises à jour majeures (1.0.0 → 2.0.0): Les modifications majeures nécessitent une mise à jour de l'App Store.

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 metadata de construction:

informations de métadonnées de construction

1.2.0+20240315.142530
Heure de déploiement pour suivi
1.2.0+ui.refresh.ténèbre
UI update description for design team
1.2.0+build.4729.commit.a1b2c3d
Numéro de build CI/CD et commit Git

Important : Le 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 d'actualisation.

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
Test de branch 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
Release candidate with UI metadata and timestamp

Utilisations réelles du Semver & stratégies d'équipe

🚀 Lancement de startup / 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, métadonnées pour le suivi de conception.

🏢 Entreprise / Réglementée

2.1.0 → Sortie trimestrielle
2.1.1+sec.patch.cve2024 → Mise à jour de sécurité avec suivi
2.2.0-rc.1+audit.ready → Candidat à l'audit préalable

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 correctif

1.2.0 → Production actuelle
1.2.1-hotfix.payment → Correction critique
1.2.1+urgent.20240315.1430 → Sortie 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 à 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 pré-production
1.4.0+prod.final.789 → Déploiement de production

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

💡 Conseils avancés :
  • Utilisez les métadonnées de construction (+) pour suivre, les horodatages ou les informations cosmétiques qui n'affectent pas la compatibilité.
  • Utilisez les identificateurs de pré-version (-) 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é semver, planifiez donc votre stratégie de canal en conséquence.

Important : Capgo utilise un versionnement semantique strict

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 différemment que la spécification le requiert. Consultez notre problème signalé et fixation tentée 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 tête non autorisé
1.0 ✗ Manque de version de patch
1.0.0.0 ✗ Trop de parties de version
1.0.0- ✗ Pré-version vide
1.0.0+ ✗ Informations de build 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.
✓ Stratégie de patch bloque 1.0.0 -> 1.0.1. Elle n'autorise que des changements de suffixe comme 1.0.0-beta.1 -> 1.0.0-beta.2.
✗ La stratégie majeure bloque les ensembles de versions 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é de semver complète, donc stable 1.0.0 est plus récent que 1.0.0-beta.2

Cet outil suit les directives officielles Spécification de la version sémantique unlike npm's implementation.