[spip-dev] [spip-commit] 8b3ee5c - branch spip-2.2 (update)

Dev
1

28/11/10, esj@rezo.net:

    La constante _EXTENSION_SQUELETTE qui indique l'extension d'un
    sauelette avait beaucoup trop d'occurrences dans le code,

Je sais que depuis la création de cette branche, il n'y a pas eu de
version 2.2.0. Malgré tout, c'est une branche stable (par opposition à
la branche de dev). Du coup, ce n'est pas le bon endroit pour faire ce
genre de changements.

Quand on sera en git, on pourra faire autant de branches thématiques
qu'on voudra ; en attendant, je dirais que la place de ce changement est
en dev.

Ou alors, ça veut dire qu'on renonce définitivement à sortir une série
2.2.x, qu'on ira directement dans les 2.3.x, et que la 2.2 est une
"autre" branche de dev... mais bof.

En tout cas, ça montre qu'on a vraiment besoin de branches thématiques
au lieu d'une unique branche de dev.

2

Yop,

28/11/10, esj@rezo.net:

   La constante _EXTENSION_SQUELETTE qui indique l'extension d'un
   sauelette avait beaucoup trop d'occurrences dans le code,

Je sais que depuis la création de cette branche, il n'y a pas eu de
version 2.2.0. Malgré tout, c'est une branche stable (par opposition à
la branche de dev). Du coup, ce n'est pas le bon endroit pour faire ce
genre de changements.

Enfin plutôt que de dire à chaque fois c'est pas le bon endroit le mieux serait de définir a priori le bon endroit pour certaines évolutions.
Une simili roadmap quoi !

Quand on sera en git, on pourra faire autant de branches thématiques
qu'on voudra ; en attendant, je dirais que la place de ce changement est
en dev.

Ou alors, ça veut dire qu'on renonce définitivement à sortir une série
2.2.x, qu'on ira directement dans les 2.3.x, et que la 2.2 est une
"autre" branche de dev... mais bof.

En tout cas, ça montre qu'on a vraiment besoin de branches thématiques
au lieu d'une unique branche de dev.

Ouais bof, on a besoin surtout d'en parler....

Eric
...qui en a marre de la technologie libère l'homme...

3

28/11/10, Eric:

Enfin plutôt que de dire à chaque fois c'est pas le bon endroit le
mieux serait de définir a priori le bon endroit pour certaines
évolutions.

C'est facile, c'est juste en dessous.

> Quand on sera en git, on pourra faire autant de branches thématiques
> qu'on voudra ; en attendant, je dirais que la place de ce
> changement est en dev.

"la place de ce changement est en dev."

4

28/11/10, davux:

28/11/10, Eric:
> Enfin plutôt que de dire à chaque fois c'est pas le bon endroit le
> mieux serait de définir a priori le bon endroit pour certaines
> évolutions.

C'est facile, c'est juste en dessous.

J'ai répondu un peu partiellement. Désolé.

Je suis d'accord avec toi qu'avant de committer direct, ça serait bien
de s'organiser sur la liste quant au meilleur moment/endroit pour
commencer ce chantier. Des branches thématiques réduiraient certes les
problèmes techniques, mais le besoin de fond reste la communication.

5

Quoting davux <da@weeno.net>:

Je sais que depuis la création de cette branche, il n'y a pas eu de
version 2.2.0. Malgré tout, c'est une branche stable

???

Il n'est pas faux de dire que cette branche est stable puisqu'elle est quasiment identique à la branche 2.1 qui elle, l'est, mais si on s'interdit d'envoyer quoi que ce soit dessus, alors c'est qu'elle ne sert à rien. On a déjà eu une longue discussion sur la raison de son existence, elle est toujours valable, je ne vais pas la réexposer.

esj

6

28/11/10, Emmanuel:

Il n'est pas faux de dire que cette branche est stable puisqu'elle
est quasiment identique à la branche 2.1 qui elle, l'est,

Ce n'est pas une question de contenu mais de nature.
Cette branche est dite stable comme toutes les branches spip-x.x.

Tel que je l'ai compris, les branches fonctionnent ainsi :

- le trunk est la branche de développement, dans laquelle se font...
  les nouveaux développements. C'est la seule partie instable.

- les branches sont toujours nommées spip-2.x et sont appelées "branches
  stables". Elles sont la ramification de l'état du trunk (tronc) à un
  instant donné. Il faut quelques modifications, les plus minimes
  possibles, pour qu'une de ces ramifications soit utilisable pour la
  première fois (on la tague 2.x.0). Par la suite, sur une branche
  donnée, on continue à faire des modifications mineures (corrections
  de bug, etc.), et ça fait des 2.x.1, 2.x.2, etc.

Si j'ai mal compris, il faut mettre à jour le wiki sur
http://core.spip.org .

mais si on
s'interdit d'envoyer quoi que ce soit dessus, alors c'est qu'elle ne
sert à rien.

Ben comme dans toute branche spip-2.x, on envoie des mises à jour de
maintenance. Mais effectivement, c'est tout : une fois que la
ramification a été faite, il faudrait s'interdire d'envoyer quoi que ce
soit de conséquent dessus, sinon c'est le cauchemar du fork, on va
devoir reporter chaque changement en parallèle dans toutes les branches
spip-2.x+1 et suivantes + le trunk.

On a déjà eu une longue discussion sur la raison de son
existence, elle est toujours valable, je ne vais pas la réexposer.

Que ce soit bien clair, je ne fais pas référence à la 2.2 en
particulier, mais au fait que ce soit une branche.

Ou alors, faire des devs dans une branche ok, mais il faudra rapidement
les resynchroniser sur le trunk, sinon les branches suivantes ne
l'auront pas, on va se prendre les pieds dans le tapis, et perdre des
trucs.

Enfin j'en sais rien, si j'ai pas saisi le workflow, je veux bien qu'on
m'explique. C'est aussi possible qu'il n'y ait aucun workflow de défini,
auquel cas prenons la description ci-dessus comme une proposition pour
combler ce flou artistique.