Ah nous voila bien embetés ...
La version stable a un numero de version base [14272]
et la version dev a un numero de version base [13929]
autant dire qu'un upgrade de stable 2.0 vers 2.1 va sauter un certain nombre d'upgrade de base...
Cette situation était à craindre depuis qu'on a enlevé le numéro de branche dans les numeros de version base.
Qui a un plan de secours ?
Cédric
Ah nous voila bien embetés ...
La version stable a un numero de version base [14272]
et la version dev a un numero de version base [13929]autant dire qu'un upgrade de stable 2.0 vers 2.1 va sauter un certain nombre d'upgrade de base...
Cette situation était à craindre depuis qu'on a enlevé le numéro de branche dans les numeros de version base.
Elle était surtout à craindre depuis qu'on se permet d'envoyer sur une branche dite stable des modifs qui ne sont pas des corrections de bugs: c'est n'importe quoi comme méthode de développement. On ne sortira jamais une nouvelle version si on passe son temps à rajouter des fonctionnalités qui ne devrait officiellement plus en admettre. Cette histoire de base, c'est le pompon, mais ça nous pendait au nez.
Qui a un plan de secours ?
A première vue je n'imagine que le scénario suivant:
Ecrire sous le numéro 14273 (ou plus) une séquence qui défait ce qui a été fait dans la base, et qui réaffecte la globale avec le numéro qu'il y avait auparavant, ce qui implique de réécrire le code qui fait la mise à jour car c'est lui qui jusqu'à présent a la maîtrise de ce numéro. Il faut probablement qu'il teste si cette globale n'a pas changé entre le moment où il a lancé la séquence associée et le moment où celle-ci lui rend la main.
Au boulot Quentin.
Committo,Ergo:Sum
Cette situation était à craindre depuis qu'on a enlevé le numéro de
branche dans les numeros de version base.Elle était surtout à craindre depuis qu'on se permet d'envoyer sur une
branche dite stable des modifs qui ne sont pas des corrections de bugs:
C'est pas moi c'est l'autre ? Whooo
-- Fil
Bon j'ai bien essayé de m'en sortir ... mais non ...
En gros je bloque sur le tour de passe passe pour avoir dans inc/version un $spip_version_base = 14280; alors que la meta est 13883
Voilà ce que j'ai fait :
C'est vraiment pas jojo
??? Bah non, c'est pas ce que je dis.
D'ailleurs il n'y avait rien de nominatif.
Je dis seulement que statistiquement, vu le nombre de modifs non liées à des bug que nous nous permettons sur cette version faussement appelée stable, un emmerd majeur allait bien finir par arriver.
Committo,Ergo:Sum
Hum, oui, mon scénario n'est valable que si on passe à la 2.1 dans la foulée. Là évidemment ça part en boucle aussi sec. Pour l'instant je ne vois pas mieux que d'attendre la sortie de la 2.1, qui aura un numéro de version N, et il faudra implanter le scénario "N vaut en fait N-P".
En attendant, je pense qu'il serait quand même bon de mettre sous le numéro 14280 la séquence qui défait ce qui a été fait en 14272, afin d'avoir une base bien équivalente au numéro qui, n'aurait pas dû changer, et surtout essayer de ne plus rien envoyer sur la 2.0 hormis des vraies corrections de bug.
Committo,Ergo:Sum
Il y a déjà une correction de bug qui necessite une maj de base qui n'a pas pu être faite sur la stable (concerne les sites syndiques dont l'etat est "'su" au lieu de "sus".
Doit on en conclure que le système actuel ne nous permet plus de corriger les bugs de la version stable qui necessitent un upgrade de la base, et qu'on doit se contenter de cette situation ?
Ni même d'enrichir la version stable des nouveaux formats de document, comme cela a été fait régulièrement sur les versions antérieures, et comme la simplement et légitimement fait quentin ?
Cédric
Il y a déjà une correction de bug qui necessite une maj de base qui n'a pas pu être faite sur la stable (concerne les sites syndiques dont l'etat est "'su" au lieu de "sus".
Doit on en conclure que le système actuel ne nous permet plus de corriger les bugs de la version stable qui necessitent un upgrade de la base,
Pas exactement: cela veut dire qu'on est forcé de faire toutes les MAJ qu'il y a eu dans la version de dev depuis. Evidemment ça peut poser pb si ces autres MAJ concernaient des fonctionnalités inexistantes dans la stable.
et qu'on doit se contenter de cette situation ?
Un bug = un emmerd', c'est pas nouveau. Si cette discpline nous (ça vaut pour moi) impose de tester mieux les sorties officielles, et de sortir de versions plus souvent (parce qu'on est bloqué par un fork potentiel de la base), de mon point de vue ce n'est pas plus mal. Je répète que je trouve aberrant le nombre de nouvelles fonctionnalités introduites dans une version dite stable. Déjà la doc est pas facilement utilisable aujourd'hui, faire sauter l'invariant "un numéro de version = un ensemble de fonctionnalités", c'est franchement n'importe qoi.
Ni même d'enrichir la version stable des nouveaux formats de document, comme cela a été fait régulièrement sur les versions antérieures, et comme la simplement et légitimement fait quentin ?
Je n'ai pas souvenir qu'on ait fait ça, peut-être que si mais ça ne change pas mon point de vue:
ce n'est PAS légitime, et l'expérience vient de montrer que ce n'est PAS simple.
Committo,Ergo:Sum
PS: tu n'as pas répondu à mon dernier mail du fil "dans le fond".