Zeste de Savoir v1.2 en approche !

Bonsoir tout le monde !

15 jours¹ 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.

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

florian tu es déjà dans un MP avec les identifiants (que j'ai envoyé au moment de la V1.1)

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

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

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)

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.

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

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 ? :

• Tags : https://github.com/zestedesavoir/zds-site/tags
• Milestones (voir les fermes pour celle en service) : https://github.com/zestedesavoir/zds-site/milestones?state=closed

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

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 ?

Apres j'ai ptet mal compris ta remarque, tu pensais ptet a autre chose ?

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

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

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

Ce sont donc des hotfixs, ok.

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.

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

Tout à fait d'accord !

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

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.

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

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.

Merci pour toutes ces petites précisions. Ca m'éclaire un peu sur notre process de release.

Ça tombe bien, j'avais les mêmes questions ;D. Du coup, j'ai mes réponses.

Sinon je veux bien aider à tester la 1.2 !

lethom je viens de t'ajouter dans un MP a ce sujet

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 ?

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

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.

Chui con j'y ai pas pensé mais on pourrait pas reprendre le code de la page de teasing pour ca ?