Zeste de Savoir v1.2 en approche !

L'auteur de ce sujet a trouvé une solution à son problème.
Staff
Auteur du sujet

Bonsoir tout le monde !

15 jours1 après la v1.1, voici que la v1.2 s'approche dangereusement de la mise en production !

Pour l'instant, elle s'est contentée d'atterrir en pré-production. Qui seront les valeureux guerriers qui oseront contrôler sa qualité pour vérifier qu'elle peut bien arriver jusqu'en production ?

En attendant cette release promet d'être bien plus légère que la précédente avec 28 issues !

  1. #935 Adapter les listes de topics aux mobiles
  2. #944 Déplacer les tags des sujets devant le titre
  3. #1149 Quelques remarques sur les tags
  4. #1170 Designer le chapitrage des tutoriels
  5. #1249 Import de tutoriel (.tuto) en zcode : Erreur 500
  6. #1260 Affichage de la licence dans les tutoriels sur les petits écrans
  7. #1341 Compresser les images sur le site
  8. #1354 Nettoyage des dépendances
  9. #1448 Badge de suivi des dépendances python du projet
  10. #1450 Incohérence dans la soumission
  11. #1452 Interprétation des textes des modales
  12. #1474 Le sous titre est souligné au hover dans les MP
  13. #1504 Double clic sur le bouton répondre = 403
  14. #1520 Rendre le code source "opensource friendly"
  15. #1533 Système pour ne pas oublier les actions spécifiques lors du déploiement
  16. #1540 Incohérences dans nos settings
  17. #1546 Bug dans les liens RSS
  18. #1552 Ajouter le support des icônes sur les alert-box
  19. #1569 Impossible de télécharger l'archive du tutoriel bêta
  20. #1577 Le karma n'est plus "voted" sur les membres récents
  21. #1579 Petites erreurs de typo sur les infobulles du karma
  22. #1581 On peut s'écrire un MP à soi-même en changeant la casse
  23. #1588 Mettre en production zds v1.2
  24. #1610 Corrections tutoriel.rst
  25. #1614 Filtre des membres par IP
  26. #1620 Les tags masquent le titre des sujets sur mobile
  27. #1628 [1.2] Impossible de signaler un message
  28. #1645 Du texte qui se chevauche dans le sommaire global d'un big tuto

Edit : C'est mis en prod, la liste des issues a été mise à jour.


  1. Littéralement. Pas "2 semaines", 15 jours :) 

Édité par SpaceFox

Je veux bien être un de ces (valeureux ?) guerriers ! :)

"Easy is right. Begin right and you are easy. Continue easy and you are right. The right way to go easy Is to forget the right way And forget that the going is easy." Chuang Tzu

+0 -0

Si c'est les mêmes, alors je vais tester ! Merci !

"Easy is right. Begin right and you are easy. Continue easy and you are right. The right way to go easy Is to forget the right way And forget that the going is easy." Chuang Tzu

+0 -0

ok , je veux bien tester aussi

#1149 Quelques remarques sur les tags
On a bien modifié le texte "LaTex", on voit la petite phrase mais le choix d'une catégorie est obligatoire.
Donc si aucune catégorie ne correspond, on est obligé d'en mettre une (qui n'est pas forcément appropriée) puis demandé à un valido pour la création d'une nouvelle catégorie?
On pourrait imaginer d'avoir une catégorie "Autre". Et que les valido veillent à ce qu'aucun tuto ne soit validé avec une telle catégorie
C'est à débattre car je suppose que si la catégorie choisie est inappropriée, le valido va de toute façon faire la remarque à l'auteur

Édité par Angelo

+0 -0

Au pire tu choisis la catégorie "ZdS" et tu en parles au valido après ? Pour le peu de tuto/articles que j'ai valide pour le moment (mes collègues confirmeront au besoin) il n'y a pas encore vraiment eu de problèmes pour les catégories. Généralement les validos anticipent la catégorie nécessaire et l'ajoute au besoin et l'auteur vient en faire part pendant la phase de validation si nécessaire aussi (même si le texte n'est pas encore présent)

ZdS, le best du Zeste ! Tuto Arduino, blog, etc

+0 -0

J'aurais quelques questions :

  • Comment sont définis les releases ? Tu te charges de créer une milestone avec un certain nombre d'issues et une fois à terme, tu fais ta release ou c'est un autre process ? Quand je vois les issues qui constituent la release, les 3/4 sont des bugs fixes et ça m'amène à une seconde question …

  • Sur quoi tu te bases pour faire une version majeure ou mineure ? Nous sommes en version majeur 1, je pense pour un petit moment. Par contre, les changements entre la version 1.1 et 1.2 sont minimes. Pourquoi ne pas avoir fait une release 1.1.1 ?

  • Sans doute liée à la question précédente, à quoi correspond le 'b' actuel dans le numéro de version actuel, à savoir Zeste de Savoir • 2014 • Version : v1.1b/c02235a.

  • Dans d'autres projets open-sources, je vois régulièrement une page qui liste toutes les releases. Disposons-nous aussi de cette fonctionnalité sur GitHub ? Si oui, comment fonctionne-t-elle ? Si non, pourquoi ?

Voilà, désolé mais je suis un peu curieux. :)

+0 -0

23.#738 case lors de l'envoie de mp
un mp envoyé à eskimon est envoyé à Eskimon :(
Par contre, pour l'envoi à soi-même (19.#1581 ça fonctionne)

@Eskimon : pour le #1149, je suis d'accord, c'est anodin et on a surement facilement moyen de contourner

Édité par Angelo

+0 -0

Sans doute liée à la question précédente, à quoi correspond le 'b' actuel dans le numéro de version actuel

Il y a eu un hotfix sur la prod' (https://github.com/zestedesavoir/zds-site/commits/prod)

Dans d'autres projets open-sources, je vois régulièrement une page qui liste toutes les releases

Comme ca ? :

Sur quoi tu te bases pour faire une version majeure ou mineure ? Nous sommes en version majeur 1, je pense pour un petit moment. Par contre, les changements entre la version 1.1 et 1.2 sont minimes. Pourquoi ne pas avoir fait une release 1.1.1 ?

Il y a quand meme des trucs majeurs ici, comme la "open-sourcabilité" du code ou le filtre IP (mais c'est vrai que tout ca se discute)


un mp envoyé à eskimon est envoyé à Eskimon

C'est normal, c'est le meme pseudo a la casse pres, donc c'est exactement le comportement voulu

ZdS, le best du Zeste ! Tuto Arduino, blog, etc

+0 -0

C'est normal, c'est le meme pseudo a la casse pres, donc c'est exactement le comportement voulu

Eskimon

ah ? ok j'avais mal lu le bug :)

Par contre, je veux pas faire mon rabat-joie mais la fonctionnalité pour un bouton qui renvoie en haut de la page n'est toujours pas implémentée :(
On a une idée si une version future (proche de préférence) prévoit ça ?

Édité par Angelo

+0 -0
Staff

Comment sont définis les releases ? Tu te charges de créer une milestone avec un certain nombre d'issues et une fois à terme, tu fais ta release ou c'est un autre process ? Quand je vois les issues qui constituent la release, les 3/4 sont des bugs fixes et ça m'amène à une seconde question …

De mémoire le but est surtout d'avoir des petites release régulière pour éviter le syndrome de la v 1.1 : longue période sans release et release énorme. Donc :

  • Aucune issue n'est assigné a priori a une milestone
  • On sort une milestone environ toutes les deux semaines avec ce qu'il y a de pret.

Sur quoi tu te bases pour faire une version majeure ou mineure ? Nous sommes en version majeur 1, je pense pour un petit moment. Par contre, les changements entre la version 1.1 et 1.2 sont minimes. Pourquoi ne pas avoir fait une release 1.1.1 ?

Perso je pense qu'il faut changer de majeur quand on casse un truc en profondeur. Genre le jour ou le module de tuto sera refactoré : Si il y a de gros changements à faire en local et de la migration.

Pour le choix entre mineur et revision, j'ai du mal a voir l'interet de faire une révision pour autre chose qu'un bug fix. Ok cette version ne chnage pas grand chose, tanpis. Mais perso j'aurai pas le courage de rentre dans un débat pour définir comment on numérote nos versions, surtout sachant qu'aucun autre site n'utilise actuellement la base de code.

Sans doute liée à la question précédente, à quoi correspond le 'b' actuel dans le numéro de version actuel, à savoir Zeste de Savoir • 2014 • Version : v1.1b/c02235a.

Un hot-fix il me semble.

Dans d'autres projets open-sources, je vois régulièrement une page qui liste toutes les releases. Disposons-nous aussi de cette fonctionnalité sur GitHub ? Si oui, comment fonctionne-t-elle ? Si non, pourquoi ?

On pourrait le faire. On ne le fait pas. Parce que personne ne s'y est mit et a montré de l'interet pour cela pour le moment. Encore une fois, l'absence d'autres sites qui utilisent notre base de code me semble expliquer pourquoi.

Voila pour mon avis :)

+0 -0

De mémoire le but est surtout d'avoir des petites release régulière pour éviter le syndrome de la v 1.1 : longue période sans release et release énorme. Donc :

Kje

C'est quelque chose qui se tient. C'est une approche itérative et j'aime bien ça.

  • Aucune issue n'est assigné a priori a une milestone

Kje

Ah bon ? Pourtant, la milestone correspondante à cette version 1.2 regroupe un certain nombre d'issues.

Il y a eu un hotfix sur la prod' (https://github.com/zestedesavoir/zds-site/commits/prod)

Eskimon

Un hot-fix il me semble.

Kje

Ce sont donc des hotfixs, ok.

Comme ca ? :

Eskimon

Non, je parle des releases. Donc plutôt comme ça : https://github.com/zestedesavoir/zds-site/releases. Je vois que ça n'a pas été maintenu pour la version 1.1.

On pourrait le faire. On ne le fait pas. Parce que personne ne s'y est mit et a montré de l'interet pour cela pour le moment. Encore une fois, l'absence d'autres sites qui utilisent notre base de code me semble expliquer pourquoi.

Kje

A première vue, cette page existe (voir juste au dessus) et elle était maintenue par firm1.

Perso je pense qu'il faut changer de majeur quand on casse un truc en profondeur. Genre le jour ou le module de tuto sera refactoré : Si il y a de gros changements à faire en local et de la migration.

Kje

Tout à fait d'accord !

Il y a quand meme des trucs majeurs ici, comme la "open-sourcabilité" du code ou le filtre IP (mais c'est vrai que tout ca se discute)

Eskimon

Oui, mais ces deux petites fonctionnalités sont noyées dans les fixes. Personnellement, je trouve cette release un poil prématuré.

Pour le choix entre mineur et revision, j'ai du mal a voir l'interet de faire une révision pour autre chose qu'un bug fix. Ok cette version ne chnage pas grand chose, tanpis. Mais perso j'aurai pas le courage de rentre dans un débat pour définir comment on numérote nos versions, surtout sachant qu'aucun autre site n'utilise actuellement la base de code.

Kje

Si nous avons une approche itérative pour les releases, je suis tout à fait convaincu du process actuel (inutile et pas envie d'un débat sur ce point non plus). Par contre, je n'aime pas trop cette excuse qu'aucun site externe utilise le code source de Zeste de Savoir. C'est justement en mettant en place tous les procédés possibles que nous pourrons être forké. Sinon, nous le serons jamais.

+0 -0
Staff
Auteur du sujet

Holà, ça poste trop vite ici. Tant pis, je répond quand même, il y aura sans doute des doublons.

Comment sont définis les releases ? Tu te charges de créer une milestone avec un certain nombre d'issues et une fois à terme, tu fais ta release ou c'est un autre process ?

C'est l'inverse en fait : on merge ce qui arrive au fur et à mesure. Quand on en a assez (plein de petits correctifs, ou une énorme modification, etc.) et que j'ai un peu de temps je lance la release avec "ce qu'il y a".

On ne fixe pas le contenu des releases à priori parce que sinon on va attendre des trucs, en faite attendre d'autres, etc… c'est pas gérable avec notre organisation.

Cf https://github.com/zestedesavoir/zds-site/blob/dev/doc/workflow.md pour les détails.

Dans le cas de la v1.2, on avait des trucs intéressants (tags, dépendances, open-source), pas mal de correctifs et ça me semblait donc le bon moment pour lancer une release. D'ailleurs, Eskimon m'a proposé la même chose le même jour :D

Ah bon ? Pourtant, la milestone correspondante à cette version 1.2 regroupe un certain nombre d'issues.

Oui : quand une PR est mergée, son ticket est ajouté à la milestone de la prochaine release.

Sur quoi tu te bases pour faire une version majeure ou mineure ? Nous sommes en version majeur 1, je pense pour un petit moment. Par contre, les changements entre la version 1.1 et 1.2 sont minimes. Pourquoi ne pas avoir fait une release 1.1.1 ?

Je te retourne la question : quel serait l'intérêt d'une numérotation type 1.1.1 ?

Je préfère conserver la numérotation simple :

  • Changement très important (ex : refonte du système de tuto/article) –> version majeure (2.0, 3.0, …)
  • Tout le reste –> version mineure (1.1, 1.2, …)
  • Si jamais on décide de tout réécrire pour une raison X ou Y… on verra à ce moment là :)

On ne gère pas 120000 version parallèles du logiciels, on a donc pas besoin de se prendre le chou avec des numéros de version compliqués du genre "v1.0.1k"

Sans doute liée à la question précédente, à quoi correspond le 'b' actuel dans le numéro de version actuel, à savoir Zeste de Savoir • 2014 • Version : v1.1b/c02235a.

Comme dit : c'est un hotfix. La lettre permet de voir tout de suite que c'est pas une release "complète".

Non, je parle des releases. Donc plutôt comme ça : https://github.com/zestedesavoir/zds-site/releases. Je vois que ça n'a pas été maintenu pour la version 1.1.

Si j'ai bien compris ce que m'a expliqué Talus, c'est plus ou moins automatique. (Edit : en fait non : https://github.com/blog/1547-release-your-software –> il faut juste que quelqu'un le fasse) Il suffirait qu'on se penche dessus pour comprendre comment continuer à déclarer des releases au sens Github.

Oui, mais ces deux petites fonctionnalités sont noyées dans les fixes. Personnellement, je trouve cette release un poil prématuré.

On a déjà 22 tickets. C'est pas négligeable du tout.

Édité par SpaceFox

Coucou,

Je réponds ici de façon à ce que ce soit global (merci à Eskimon pour le petit MP ^^ ) : malheureusement je ne pourrai pas être de la partie pour cette fois, car je m'absente pour une durée d'une semaine.

Mais ce sera avec plaisir une prochaine fois, bien entendu :)

PS : puisqu'il est apparemment prévu de proposer une préprod pour chaque version, pourquoi ne pas avoir un système permettant de s'inscrire automatiquement via une page spéciale avec un bouton semblable au « S'inscrire au cours » d'un site orange ? Un système enverrait ensuite automatiquement un mail aux inscrits quand une préprod est disponible… Voire un MP de la part de Clem ? :)

Édité par Jérôme Deuchnord

A graphical interface is like a joke: if you have to explain it, that's shit. | Les logiciels Deuchnord

+0 -0

PS : puisqu'il est apparemment prévu de proposer une préprod pour chaque version, pourquoi ne pas avoir un système permettant de s'inscrire automatiquement via une page spéciale avec un bouton semblable au « S'inscrire au cours » d'un site orange ? Un système enverrait ensuite automatiquement un mail aux inscrits quand une préprod est disponible… Voire un MP de la part de Clem ? :)

Vu le nombre de preprod et leur fréquence, ca semble etre beaucoup de dev pour peu de choses :D

ZdS, le best du Zeste ! Tuto Arduino, blog, etc

+0 -0
Staff

Moi je trouvais l'idée assez pertinente. On va avoir a la louche un passage en pré prod tous les 15 jours ou 3 semaines, ce qui n'est pas si peu souvent que ça. On est loin d'avoir trop de testeurs. Et enfin un mail permet de prévenir les membres même si ils ne viennent ici que irrégulièrement.

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte