Passer à la navigation principale

Capgo Tester de la version Semver

Vérifiez la compatibilité de la politique du canal par rapport à la référence native envoyée sous version_build

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

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

Entrez deux versions sémantiques pour voir la comparaison

What signifie "Version de base native"

La Version de base native est la version d'application native envoyée à Capgo version_build lorsque le dispositif demande au serveur d'actualisation un bundle. Dans une application Capacitor, cette valeur peut provenir de CapacitorUpdater.version en capacitor.config.*. Si ce paramètre n'est pas présent, le plugin se réfère à la version d'application native de iOS ou Android. N'assumez pas qu'il s'agit de votre package.json version sauf si votre build copie cette valeur dans la configuration ou les métadonnées natives.

Capgo utilise toujours version_name pour déterminer quel bundle téléchargé est actuellement installé. Les politiques de version semver du canal, comme major, minoret patch comparent le bundle téléchargé à version_build.

Capacitor configuration

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

Avantages : facile à maintenir identique sur les builds iOS et Android.

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

Version de l'application native

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

Avantages : correspond à la version des binaires installés à partir de TestFlight, de l'App Store, de Google Play ou de la mise en test interne.

Con: Changer cela nécessite une mise à jour native et peut différer par plateforme si les paramètres de mise à jour divergent.

Cible de paquet

Comparez-l’avec les versions de paquets distants, les règles de canal semver 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: Les 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, saisissez la base native que le dispositif envoie sous la forme version_buildet comparez-l’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 de la livraison de mises à jour en direct vers vos Capacitor applications.

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): Bug fixes, safe to apply automatically
  • Mises à jour mineures (1.0.0 → 1.1.0): New features, backward compatible
  • Mises à jour majeures (1.0.0 → 2.0.0): Changements de rupture, nécessitant une mise à jour native de l'application

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 Élastiques : Au-delà de la Versionnement Basique

Même si semver est strict sur son format de base, vous pouvez l'étendre pour répondre aux besoins de votre équipe. des identificateurs de pré-version et informations de construction:

🏷️ Informations de Build (+) - La "Couche Cosmétique"

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 : Build metadata is ignored in version precedence - 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
Chaîne de test 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
Release candidate with UI metadata and timestamp

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

🚀 Lancement rapide / Développement rapide

0.1.0 - Première version MVP
0.2.0-beta.1 - Test de nouvelles fonctionnalités
0.2.0+ui.v2 Méta-données de la nouvelle 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 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 à l'audit préalable

Semver stricte avec métadonnée de conformité

🎮 Jeux / Applications créatives

1.0.0+season.winter.2024 → Contenu saisonnier
1.1.0+event.halloween → Fonctionnalités basées sur des événements
1.2.0+assets.hd.remaster → Mises à jour d'actifs

Méta-données créatives pour le suivi du contenu

⚡ Stratégie de correction d'urgence

1.2.0 → Production actuelle
1.2.1-hotfix.payment → Correction critique de bogues
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-plateformes

1.3.0+ios.optimized → Optimisations spécifiques à iOS
1.3.0+android.material3 → Mises à jour de conception Android
1.3.0+web.pwa.ready → Capacités de PWA

Même version, métadonnées de plateforme spécifiques

🔄 Intégration CI/CD

1.4.0-alpha.1+build.123 → Déploiement automatique de pré-version
1.4.0+deploy.staging.456 → Déploiement de production
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 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 une versionnement semantique stricte

Par rapport à 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 de ce que la spécification exige. Voir notre problème signalé et correction tentée tentative de correction

Versions Sémantiques Valides

1.0.0 Versions Sémantiques Valides
2.1.3-alpha ✓ Pre-release
1.0.0-beta.1 ✓ Version préliminaire 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 ✗ Le 'v' en tête n'est pas 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+ ✗ Métadonnées de construction vides

Capgo Comportement de mise à jour

✓ La stratégie mineure permet des changements 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 changements 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 au niveau de base natif, par exemple 1.0.0 -> 2.0.0
⚠ La protection de downgrade utilise la préférence semver complète, donc stable 1.0.0 est plus récent que 1.0.0-beta.2

Cet outil suit la version officielle Spécification de la version sémantique La version de npm n'est pas conforme à la spécification