VDigital a écrit:

Une belle machine, elle brille, et c'est une bombe.

J'adore... ;-)

VDigital a écrit:

z0rglub n'a pas fait de script d'upgrade. Oui, et je trouve qu'il a raison.
C'est la chienlit à mettre en place, il sera dans l'obligation de la faire pour la version finale certes.

Et donc pas de possibilité de tester la migration d'une version à une autre! (C'est ce que j'avais envie de faire dans un premier temps)
Normalement pas d'évolutions majeures entre la 1.7.0RC1 et la finale => idem pour les upgrade.

VDigital a écrit:

Mais pour moi c'est inutile.

Moi, je pense le contraire.
Dans le même ordre d'idée, j'intégrerais les fichiers upgrade dans la BSF d'autant plus qu'on ne tire plus de branche mais qu'on tag.

Voila, ce n'est que mon point de vue, qu'en pense, le reste de l'équipe?

rub a écrit:

Il y a des petits détails qui me chagrine dans la 1.7.0RC1 :

  1 : C'est mineure, mais je trouve que la liste de nouveautés n'est pas assez complétés à mon gout
   Manque la notification des commentaires, le nouveau script pour les sites distants, les compteurs sur toutes les branches, etc... Bref, rien de grave

J'avoue que j'ai moins bien suivi les développements en 1.7 qu'auparavant (manque de temps de manière générale et aussi, vous êtes plus nombreux à en faire davantage). Donc il est fort possible que j'ai loupé des choses. L'important, ce sera la newsletter sur la 1.7.0. Un peu comme on avait fait [wiki] fr:release:1.6.0, l'équivalent pour la 1.7.0 serait fort utile.

A noter tout de même que dans ma newsletter, j'ai essayé de ne lister que des évolutions fonctionnelles, pas techniques (bon, ce n'est peut-être pas ce que j'ai parfaitement fait, mais dans l'idée, c'est ce que je voudrais faire).

Bref, merci pour le petit rappel à l'ordre, j'ai été un peu vite (je voulais respecter la date, il a fallu tout faire entre 22h et minuit). Je compte notamment sur toi pour m'aider à faire une meilleure newsletter 1.7.0 :-).

rub a écrit:

2 : La, ca me gène plus.
Pour moi, un RC est une version pouvant potentiellement être une version finale.
Et dans ce qui a été mis à disposition, je ne trouve pas les script de mise à jour d'une version antérieure vers la 1.7.0RC1.
Est-ce normal? Ou un oubli?

En 1.5 et antérieur, je n'incluais jamais les outils d'upgrade dans les RCs. Et j'ai oublié que je les avais inclus en 1.6.0RC1 (j'ai ajouté ces outils en branche 1.6 r1174 et r1209 alors que la 1.6.0RC1 correspond à la branche 1.6 en r1320).

Conclusion: c'est un oubli, j'aurai dû les mettre. Je suis parfaitement d'accord sur le fait qu'inclure les scripts d'upgrade dans les RCs permet de les tester. Les ajouter uniquement dans la release finale, c'est dangereux (et risque de -//:---\spam à sortir rapidement une 1.7.1).

VDigital a écrit:

Tiens, tu devrais te faire une petite procédure pour ne rien oublier... non?

Oui. J'ai déjà une checklist pour une release "normale" (template basée sur la 1.6.0):

checklist de Pierrick a écrit:

Avant de créer une release :

- création du tag tags/release-1_6_0

- les paramètres de configuration à changer sont :
  - $conf['check_upgrade_feed'] = false;
  - $conf['show_version'] = false;
  - $conf['show_gt'] = false;
  - $conf['die_on_sql_error'] = false;

- virer le répertoire install/db ou n'insérer en base que le différentiel

- fabrication de la release + upload

- mise à jour de la page de présentation (dernière release, les liens de
téléchargement, la liste des fonctionnalités) et du latest_release

- mise à jour du wiki (fr:release + en:releases_history)

- mise à jour de la demo

- notification de Freshmeat

- phpwebgallery-announce

- phpwebgallery-announce-french

- information sur l'entête du forum

- news sur Gna!

- dépêche sur linuxfr.org

- billet sur mon blog

- ajouter la release 1.6.0 et la 1.6.1 dans le bugtracker

- ajouter la release 1.6.0 dans l'extension manager

Faut que je la complete :-)

rub a écrit:

Par contre, tu as vu que dans la version en anglais, il propose des liens vers la 1.6!

Oui, je m'en suis rendu compte... trop tard malheureusement. Et je n'ai aucun moyen de corriger a posteriori.

rub a écrit:

z0rglub a écrit:

En 1.5 et antérieur, je n'incluais jamais les outils d'upgrade dans les RCs. Et j'ai oublié que je les avais inclus en 1.6.0RC1 (j'ai ajouté ces outils en branche 1.6 r1174 et r1209 alors que la 1.6.0RC1 correspond à la branche 1.6 en r1320).

Conclusion: c'est un oubli, j'aurai dû les mettre. Je suis parfaitement d'accord sur le fait qu'inclure les scripts d'upgrade dans les RCs permet de les tester. Les ajouter uniquement dans la release finale, c'est dangereux (et risque de -//:---\spam à sortir rapidement une 1.7.1).

Et donc, tu ne penses pas qu'on devrait les inclure alors dans la BSF?

Non, sur trunk (alias BSF), on utilise upgrade_feed.php, pas upgrade. C'est ingérable sinon. Ce n'est pas parce que c'est moi qui l'ai fait, mais upgrade_feed.php, c'est une évolution technique majeure pour le travail en équipe (quelle galère avant). Bref, non, pas d'upgrade.php sur trunk.

Je crois qu'on saurait très vite inclure les changements nécessaires à upgrade.php si effectivement il était en trunk.
On peut même ajouter un contrôle pour éviter de l'utiliser si l'upgrade_feed est actif...

8-)

z0rglub a écrit:

Maintenant qu'on a les scripts d'upgrade en trunk, je compte faire (ce soir ?) la branche 1.7 et la release 1.7.0RC2 dans la foulée. Tout le monde est d'accord ?

Si je dis non, c'est que je suis maso....

Je dis donc un grand OUI...

+1