Re: [Dotclear Dev] Autoupdate sexy ?
by Jean-Christian Denis
Cool ça va me faciliter la vie! Merci chef
xave <xave(a)xave.org> a écrit :
>Salut les gens,
>
>Actuellement, les trois branches de l'auto-update sont :
>stable : la dernière release
>testing : nightly de la branche en cours de la dernières release
>(actuellement branche 2.4)
>unstable : nightly de du "trunk" (actuellement branche default)
>
>Je viens de rajouter, pour les intrépides, la branche sexy, simplement
>nommée "sexy", si vous voulez mettre à jour vos fichiers de config.
>Attention, ne faites pas ça sur un blog de prod, évidemment.
>
>Note aux devs qui jouent avec celle-là : n'oubliez pas, quand vous
>virez un plugin ou un js, qu'il peut falloir mettre à jour le
>Makefile, sinon ça casse la compilation et poum, plus de nightlies.
>
>xave
>_______________________________________________
>Dev mailing list
>Dev(a)list.dotclear.org
>http://ml.dotclear.org/listinfo/dev
11 years, 8 months
Autoupdate sexy ?
by xave
Salut les gens,
Actuellement, les trois branches de l'auto-update sont :
stable : la dernière release
testing : nightly de la branche en cours de la dernières release
(actuellement branche 2.4)
unstable : nightly de du "trunk" (actuellement branche default)
Je viens de rajouter, pour les intrépides, la branche sexy, simplement
nommée "sexy", si vous voulez mettre à jour vos fichiers de config.
Attention, ne faites pas ça sur un blog de prod, évidemment.
Note aux devs qui jouent avec celle-là : n'oubliez pas, quand vous
virez un plugin ou un js, qu'il peut falloir mettre à jour le
Makefile, sinon ça casse la compilation et poum, plus de nightlies.
xave
11 years, 8 months
CHANGELOG 2.4.4
by xave
Hop,
Les gars, on ne sort pas une 2.4.4 avec un CHANGELOG vide. Je mets
quoi à part "Bugfix: Programmed posts" ?
xave
11 years, 8 months
Communication sur la branche sexy
by Dsls
Re,
Le chantier avance, c'est peut-être un peu tôt pour en parler tant
qu'on n'a pas un peu plus avancé, mais autant anticiper la mécanique
derrière.
Comme je le disais, une chose manque cruellement à dotclear en terme
de comm' : le distingo clair entre la version officielle et la version
de dev.
Jusqu'à présent, on avait une release majeure, et on donnait une
petite visibilité sur les nightly builds. Dans la nouvelle approche,
l'idée serait de donner de la visibilité sur la version de
développement, afin de sensibiliser les thémeurs/plugineurs sur ce
qu'il y a à modifier pour que leurs ouvrages fonctionnent avec la
prochaine version.
Je tire les enseignements de la vague de messages du forum suite à la
2.3, qui introduisait quelques changements liés à php 5.3, et posait
des problèmes de compatibilité des plugins. L'erreur à mon avis a été
de ne pas assez communiquer en amont sur les nightly, ce qui fait que
les utilisateurs se sont retrouvés du jour au lendemain avec une
nouvelle version de dotclear, et des plugineurs pris de court.
Il faudra donc qu'on mette sur le site officiel, un lien vers la
version beta, avec une page décrivant les évolutions majeures qu'elle
contient, ainsi qu'une page décrivant comment adapter les
plugins/thèmes pour qu'ils soient compatibles avec la beta.
Je pense aussi faire un petit bout de code (emplacement d'hébergement
à définir) qui analysera un plugin/thème, et indiquera s'il est
compatible ou non avec la beta.
--
Bruno
11 years, 8 months
Re: [Dotclear Dev] Communication sur la branche sexy
by Jean-Christian Denis
Ha ben si la bugfix peut sortir demain je pense...
Philippe <philippe(a)dissitou.org> a écrit :
>Le 12 août 2012 13:27, xave <xave(a)xave.org> a écrit :
>>> Le chantier avance, c'est peut-être un peu tôt pour en parler tant
>>> qu'on n'a pas un peu plus avancé, mais autant anticiper la mécanique
>>> derrière.
>>
>> Demain c'est l'anniversaire, c'est toujours un peu tôt pour en parler
>> ? Parce que ce serait l'occase. (en plus de la bugfix qui est prévue,
>> pour laquelle je pars du principe que tout est prêt dans la bonne
>> branche, donc.)
>
>Pour l'anniversaire, ce serait vraiment bien de faire une annonce,
>oui, mais pas forcément une release : attendre la rentrée nous
>assurerait l'attention et la participation des utilisateurs, ce qui
>n'est pas gagné en plein mois d'août
>
>C'est donc au chef de décider :P
>
>--
>Philippe
>_______________________________________________
>Dev mailing list
>Dev(a)list.dotclear.org
>http://ml.dotclear.org/listinfo/dev
11 years, 8 months
[Sexy] la fin du ->fetch()
by Dsls
Re,
Un commit d'il y a quelques temps sur clearbricks rend désormais la
chose faisable : la branche sexy verra l'abandon des while
($rs->fetch()).
Principale motivation : il n'y a pas de raisons que les boucles se
fassent uniquement sur un résultat en base de données.
La classe record étant désormais Iterable, les :
while ($rs->fetch())
Deviendront
foreach ($results as $rs)
NB : les ->fetch seront toujours accessibles, mais plus utilisés au
niveau du core.
--
Bruno
11 years, 8 months
Liste exhaustive themes/plugins
by Dsls
Re, ce serait possible de recenser quelque part une liste la plus
exhaustive possible de l'ensemble des thèmes et plugins dotclear ?
J'ai quelques moulinettes (sécu notamment)que j'aimerais faire tourner sur
la base potentielle de tout le code autour de dotclear.
--
Bruno
11 years, 8 months
[Sexy+clearbricks] PDO
by Dsls
Hello,
Il y a un truc qui me brûle les doigts depuis un certain temps : le passage
des accès en base par PDO. Outre le fait que c'est vers ces drivers que la
tendance va et qu'à terme les autres risquent de disparaître, c'est bien
plus propre à coder, et ça permet surtout de mieux sécuriser les requêtes
(via les prepared statements).
Je pense qu'en plus une couche de compatibilité ne sera pas trop compliquée
à mettre en place...
Des objections?
--
Bruno
11 years, 8 months
[Sexy] Installation/mise à jour des plugins, suite
by Dsls
Hello,
Je viens de réexaminer le mode d'installation/mise à jour des plugins
actuels, et ça manque de logique :
* toute la logique de mise à jour de numéro de version, de test de
mise à jour du plugin sont délégués au plugin.
* à chaque passage dans admin/index.php, tous les _install.php des
plugins sont appelés.
Impact direct : seuls les plugins disposant d'un _install.php font
l'objet d'un "les plugins suivants ont été mis à jour" à l'accueil de
l'admin, et disposent d'une entrée dédiée dans la table dc_version.
C'est ballot.
Dans la branche sexy, la prise en charge des mises à jour du numéro de
version se fera via le core, chaque plugin aura sa version dans
dc_version, et les _install.php ne seront appelés qu'à bon escient.
Probable aussi qu'un _upgrade.php voit le jour, pour les mises à jour
multi-blog potentiellement chronophages...
--
Bruno
11 years, 8 months
