Comment les modules viennent avec leur vert, jaune et rouge de presse?

Question

Comme nous le savons tous, pas tous les modules marqués « Release recommandé » à la drupal.org est vraiment stable. En fait, certains modules sont perpétuellement marqués bêta, dans une sorte d'état de limbes permanent. Même lorsque des centaines de sites les utilisent tous les jours.

Je me demandais quel genre de normes ou meilleures pratiques n'utilisez-vous, en tant que mainteneur ou contributeur, dans vos modules à marque de presse « recommandés » (vert), « Autre » (jaune), ou « Dev » (Rouge) ? Qu'est-ce que vous utilisez quand le marquer bêta, alpha ou stable ainsi?

Merci d'avance pour tout conseil, l'aide ou la documentation que vous pouvez fournir.

NOTE: Un grand nombre de ces normes peuvent être des normes générales pour le codage ou le développement de projets. Je voulais simplement savoir quelles sont les méthodes ou les normes sont utilisées dans les modules Drupal spécifiquement, même si elles sont / peuvent être généralisées.

Answer 1

Un grand nombre de ces normes peut être des normes générales pour le codage ou le développement du projet.

Dans Drupal il n'y a pas de norme pour cela. Il reste aux meilleures intentions des propriétaires du module.

Ma philosophie personnelle est:

• version bêta et / ou releasecandidate si testé dans un environnement de test, ou si toutes testcases passe.
• version stable que si je, moi-même, ont implémenté avec succès la (version du) module dans au moins trois différents projets dans le monde réel; ou si quelqu'un que je connais a mes normes, a fait cela et fait rapport.
• Un module peut être fini . Il n'a pas besoin d'un travail supplémentaire jamais plus. Quelque chose qui est limité et scope dans featureset, est stable et prévisible. Ces modules ont pas besoin de corrections de bogues, fonctionnalités demandes ou des tâches.

En pratique, cela signifie très peu de presse, mais les versions faites affecteront presque personne. Cela se traduit dans presque jamais rien relâcher dans la pratique.

Mon raisonnement est:

• Les gens en question-files d'attente tester de façon appropriée à peine: ils appliquent une fonction, fixe ou patch, coup f5, voir travailler et dire « oui, fonctionne pour moi +1 ». "Il semble fonctionner" est pas égal à "il est fixé" . Vous avez besoin de tests fiables, ou bien le reste, ceux qui ne constitue même le changement, afflueront dans les questions de rapports quelque chose compeletely BORKEND, besoin fix MAINTENANT !!.
• uniquement lorsqu'un module est mis en œuvre dans des environnements et des situations différentes, il sera avoir une certaine expérience dans le monde réel. Le plus souvent, au cours de la deuxième mise en œuvre vous trouvez que vous avez besoin de réécrire certains paramètres de api central, oublié un peu utile, ou avait simplement une mauvaise idée de la nécessité d'une caractéristique. Seulement après le déploiement dans le monde réel peut être considéré comme quelque chose de stable. Sinon, il est stable en théorie.
• Les développeurs et mainteneurs de sites, les utilisateurs de vos modules, doivent mettre un énorme effort (beaucoup plus que dans tout autre logiciel que je sais) en accord avec les nouvelles versions, les versions de sécurité et de nouvelles versions. un soulagement pour cet effort (et le budget et le temps) devrait être plus alors bienvenue.

Answer 2

S'il y a un module que vous utilisez où vous avez trouvé des bugs la meilleure chose que vous pouvez faire est de déposer une question. Mieux encore est si quelqu'un écrit un patch pour cette question, le patch peut être écrit par un développeur qui a besoin de la fonctionnalité ou il peut être écrit par un développeur qui a obtenu parrainé pour écrire ce patch. mainteneurs contrib maintiennent généralement beaucoup de modules et lorsque vous créez un module vous devenez automatiquement le mainteneur, inutile de dire que met beaucoup de pression sur nous, donc nous alway besoin d'aide par des gens qui écrivent des patchs, correctifs de parrainage ou les passer en revue.

Lorsque vous maintenez les rejets dans drupal.org vous avez un « pris en charge » case à cocher, permettant qui vous donnera un communiqué recommandé (vert) et si vous activez également "la libération Afficher la vous obtiendrez une version dev (rouge) . Si vous avez plus d'une version majeure de votre module (6.1 et 6.2), vous pouvez choisir celui qui sera dans la la section de sortie recommandé (vert). Seuls les bêtas et versions régulières vont dans le « recommandé » section (vert) alphas et versions inférieures seront affichés dans la section 'autres versions de (jaune).

Answer 3

En ce qui concerne bêtas, rcs et dev, cela dépend de la popularité et de niche votre module remplit imo.

Si earl déployé une version officielle de vues qui ont eu un problème de perte de données Internet comme un ensemble cesse de puissance à la fonction.

Cependant, si vous avez un petit module qui est relativement impopulaire (> 1000 utilisateurs) et vous êtes tout simplement passer juste par routine des corrections de bugs, il est plus raisonnable de simplement faire de nouvelles versions et non bêta / rc eux.

si vous savez que vous avez fait quelques grands chnages ou vu beaucoup de désabonnement puis testez plus thouroughly.

J'ai tendance à tester et rouleau bêtas / rc quand je suis en train de modifier la base de données ou l'émission mise à jour () crochets parce que je me rends compte de la permanence de la perte de données. Je peux et reroll rééditer un petit bug solution rapide à droite le monde, mais je peux recréer vos données sites.

L'espoir qui aide.