Mysql: Veuillez étiqueter une nouvelle version

Créé le 27 oct. 2017  ·  3Commentaires  ·  Source: go-sql-driver/mysql

Il y a 42 commits depuis la 1.3.

organization

Commentaire le plus utile

Quel est le dernier statut d'une potentielle version v1.4 ? Y a-t-il des problèmes concrets qui font de cette version un problème ? Comment puis-je aider à créer une nouvelle version ?

Je pense que vous pourriez simplement prendre le tout dernier commit comme début de disons _v1.4_. Si les gens utilisent ensuite cette version dans leur configuration Dep, par exemple comme version=^v1 ou même version=v1.4 et trouvent des bogues critiques, nous pourrions publier v1.4.1 et les utilisateurs obtiendront implicitement la correction du bogue ; à part ne pas couper la version, les gens de FUD ne comptent pas sur branch=master mais plutôt revision=X et se rendent compte très tard qu'un correctif de bogue est déjà disponible pour eux.

Tous les 3 commentaires

Et quelques autres suivront avant que nous annoncions une autre version .

Si vous vous sentez courageux, utilisez la pointe (branche principale) et donnez votre avis.
Nous avons apporté des modifications fonctionnelles plus importantes au cours du cycle actuel, par exemple la prise en charge de plusieurs résultats (qui devrait être plutôt stable maintenant) et des modifications de la logique de nouvelle tentative (#302) qui nécessite probablement d'autres ajustements (#657) avant de pouvoir la publier. aussi stable .

Vous pouvez accélérer l'ensemble du processus en contribuant ou simplement en résolvant les problèmes généraux qui nous empêchent de préparer la prochaine version.
Nous recherchons avec impatience des contributeurs plus actifs à ce projet. AFAIK, les 3 membres actuels de l'équipe y travaillent exclusivement pendant leur temps libre. Malheureusement, aucun d'entre nous ne semble actuellement avoir beaucoup de temps à perdre.
Si votre entreprise (adressée à tous ceux qui lisent ceci) en dépend, mon conseil serait de vous assurer que quelqu'un qui est payé travaille régulièrement sur ce sujet pendant le temps de travail .

Si le master actuel est moins stable que la balise v1.3 , alors la section Installation du README devrait probablement le mentionner ? Avoir une politique de version explicite devrait être bénéfique pour les utilisateurs.

Quel est le dernier statut d'une potentielle version v1.4 ? Y a-t-il des problèmes concrets qui font de cette version un problème ? Comment puis-je aider à créer une nouvelle version ?

Je pense que vous pourriez simplement prendre le tout dernier commit comme début de disons _v1.4_. Si les gens utilisent ensuite cette version dans leur configuration Dep, par exemple comme version=^v1 ou même version=v1.4 et trouvent des bogues critiques, nous pourrions publier v1.4.1 et les utilisateurs obtiendront implicitement la correction du bogue ; à part ne pas couper la version, les gens de FUD ne comptent pas sur branch=master mais plutôt revision=X et se rendent compte très tard qu'un correctif de bogue est déjà disponible pour eux.

Cette page vous a été utile?
0 / 5 - 0 notes