Je me suis lancé dans une petite mise à jour des crayons, histoire de
faire un peu d'archéologie :).
Si supprimer les librairies en doublons (cQuery et JavaScriptPacker)
était l'objectif initial. J'en ai profité pour faire quelques amélioration.
Cette version n'est que pour SPIP 3.0 et plus. Cependant, je n'ai testé
que sur SPIP 3.2, n'aillant plus que cela de disponible.
Je sais que c'est un plugin largement utilisé avec plein de
configuration différente. Il est donc possible que certaines choses soit
cassées pour X ou Y raisons.
J'ai mis le plugin dans une branche
(https://zone.spip.org/trac/spip-zone/browser/plugins/crayons/branches/v3)
et je l'ai passé en test.
L'idée est de laisser un peu de temps pour tester les trucs critiques
avant d'en faire, si possible, la version par défaut pour SPIP 3.
Et quand tu stabilises tu passe ça dans le trunk ?
Yep
Il aurait pas fallut dev dans le trunk plutôt ?
Peut être, je ne sais jamais.
Pour moi une façon saine de faire, comme avec Git :
Le trunk contient la version stable. Les branches contiennent les
développements qui seront fusionné par la suite.
L'idée est d'avoir toujours une version stable a exploiter.
Pierre KUHN <pierrekuhn82@gmail.com> writes:
Bonsoir,
Et quand tu stabilises tu passe ça dans le trunk ?
Il aurait pas fallut dev dans le trunk plutôt ?
Le 28 janvier 2018 à 20:27, Debondt Didier <p@henix.be> a écrit :
Hello les amis du SPIP,
Je me suis lancé dans une petite mise à jour des crayons, histoire de
faire un peu d'archéologie :).
Si supprimer les librairies en doublons (cQuery et JavaScriptPacker)
était l'objectif initial. J'en ai profité pour faire quelques amélioration.
Cette version n'est que pour SPIP 3.0 et plus. Cependant, je n'ai testé
que sur SPIP 3.2, n'aillant plus que cela de disponible.
Je sais que c'est un plugin largement utilisé avec plein de
configuration différente. Il est donc possible que certaines choses soit
cassées pour X ou Y raisons.
J'ai mis le plugin dans une branche
(Connexion · GitLab
crayons/branches/v3)
et je l'ai passé en test.
L'idée est de laisser un peu de temps pour tester les trucs critiques
avant d'en faire, si possible, la version par défaut pour SPIP 3.
Cela implique de changer tout le temps l'archivelist avec la bonne
branche à distribué.
Si tu merges les nouveautés quand elles sont stables dans le trunk, tout
le monde les reçois en même temps sans autre besoin.
Après, c'est juste une façon de faire, on peux discuter des heures de
ce qui est mieux.
Pierre KUHN <pierrekuhn82@gmail.com> writes:
Pour moi on dev en trunk et on branches avant de gros changement....
On va du mal a suivre avec svn up il me semble.
Le 28 janvier 2018 à 20:49, Debondt Didier <p@henix.be> a écrit :
Hello,
> Et quand tu stabilises tu passe ça dans le trunk ?
Yep
> Il aurait pas fallut dev dans le trunk plutôt ?
Peut être, je ne sais jamais.
Pour moi une façon saine de faire, comme avec Git :
Le trunk contient la version stable. Les branches contiennent les
développements qui seront fusionné par la suite.
L'idée est d'avoir toujours une version stable a exploiter.
Pierre KUHN <pierrekuhn82@gmail.com> writes:
> Bonsoir,
>
> Et quand tu stabilises tu passe ça dans le trunk ?
>
> Il aurait pas fallut dev dans le trunk plutôt ?
>
> Le 28 janvier 2018 à 20:27, Debondt Didier <p@henix.be> a écrit :
>
>> Hello les amis du SPIP,
>>
>> Je me suis lancé dans une petite mise à jour des crayons, histoire de
>> faire un peu d'archéologie :).
>>
>> Si supprimer les librairies en doublons (cQuery et JavaScriptPacker)
>> était l'objectif initial. J'en ai profité pour faire quelques
amélioration.
>>
>> Cette version n'est que pour SPIP 3.0 et plus. Cependant, je n'ai testé
>> que sur SPIP 3.2, n'aillant plus que cela de disponible.
>>
>> Je sais que c'est un plugin largement utilisé avec plein de
>> configuration différente. Il est donc possible que certaines choses soit
>> cassées pour X ou Y raisons.
>>
>> J'ai mis le plugin dans une branche
>> (Connexion · GitLab
>> crayons/branches/v3)
>> et je l'ai passé en test.
>> L'idée est de laisser un peu de temps pour tester les trucs critiques
>> avant d'en faire, si possible, la version par défaut pour SPIP 3.
>>
>> Voilà voilà
>> ----
>> spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
>>
Je dirais plutôt dans un tag.
Mais cela ne change pas grand chose branches/tag
Pierre KUHN <pierrekuhn82@gmail.com> writes:
Et la version actuellement distribuer tu la ranges en branches/V1 du coup
après ?
Le 28 janvier 2018 à 20:59, Debondt Didier <p@henix.be> a écrit :
Cela implique de changer tout le temps l'archivelist avec la bonne
branche à distribué.
Si tu merges les nouveautés quand elles sont stables dans le trunk, tout
le monde les reçois en même temps sans autre besoin.
Après, c'est juste une façon de faire, on peux discuter des heures de
ce qui est mieux.
Pierre KUHN <pierrekuhn82@gmail.com> writes:
> Pour moi on dev en trunk et on branches avant de gros changement....
>
> On va du mal a suivre avec svn up il me semble.
>
> Le 28 janvier 2018 à 20:49, Debondt Didier <p@henix.be> a écrit :
>
>> Hello,
>>
>> > Et quand tu stabilises tu passe ça dans le trunk ?
>>
>> Yep
>>
>> > Il aurait pas fallut dev dans le trunk plutôt ?
>>
>> Peut être, je ne sais jamais.
>> Pour moi une façon saine de faire, comme avec Git :
>>
>> Le trunk contient la version stable. Les branches contiennent les
>> développements qui seront fusionné par la suite.
>> L'idée est d'avoir toujours une version stable a exploiter.
>>
>> Pierre KUHN <pierrekuhn82@gmail.com> writes:
>>
>> > Bonsoir,
>> >
>> > Et quand tu stabilises tu passe ça dans le trunk ?
>> >
>> > Il aurait pas fallut dev dans le trunk plutôt ?
>> >
>> > Le 28 janvier 2018 à 20:27, Debondt Didier <p@henix.be> a écrit :
>> >
>> >> Hello les amis du SPIP,
>> >>
>> >> Je me suis lancé dans une petite mise à jour des crayons, histoire de
>> >> faire un peu d'archéologie :).
>> >>
>> >> Si supprimer les librairies en doublons (cQuery et JavaScriptPacker)
>> >> était l'objectif initial. J'en ai profité pour faire quelques
>> amélioration.
>> >>
>> >> Cette version n'est que pour SPIP 3.0 et plus. Cependant, je n'ai
testé
>> >> que sur SPIP 3.2, n'aillant plus que cela de disponible.
>> >>
>> >> Je sais que c'est un plugin largement utilisé avec plein de
>> >> configuration différente. Il est donc possible que certaines choses
soit
>> >> cassées pour X ou Y raisons.
>> >>
>> >> J'ai mis le plugin dans une branche
>> >> (Connexion · GitLab
>> >> crayons/branches/v3)
>> >> et je l'ai passé en test.
>> >> L'idée est de laisser un peu de temps pour tester les trucs critiques
>> >> avant d'en faire, si possible, la version par défaut pour SPIP 3.
>> >>
>> >> Voilà voilà
>> >> ----
>> >> spip-zone@rezo.net - http://listes.rezo.net/
mailman/listinfo/spip-zone
>> >>
>>
Indépendamment des mérites de l’une ou l’autre méthode, je pense qu’il est important que tous les plugins de la zone soient rangés de la même façon.
Il me semble que le rangement convenu est le suivant : « un dossier trunk pour la version en cours de développement et un dossier branches qui contient les différentes branches du plugin », cf. Avec cette convention de rangement, je m’attends à trouver la dernière version dans le trunk (qu’elle soit stable ou en dev). Aussi, pourquoi passer directement de la v1.26.x à la v3 ?
Pareil, je croyais que tout le monde était assez d’accord pour ranger tous les plugins de la même manière. Et en général, tout peut se discuter sur les listes, puisque ça concerne tout le monde…
Aussi passionnante que soit ces discutions sur le "comment j'aurai du
organiser les dossiers" et/ou "pourquoi 3 et pas 2", est-ce qu'on pourrai
ne pas ce perdre et revenir au sujet principal ?
Je sais que c'est un plugin largement utilisé avec plein de
configuration différente. Il est donc possible que certaines choses soit
cassées pour X ou Y raisons.
J'ai mis le plugin dans une branche
(Connexion · GitLab)
et je l'ai passé en test.
L'idée est de laisser un peu de temps pour tester les trucs critiques
avant d'en faire, si possible, la version par défaut pour SPIP 3.
Aussi passionnante que soit ces discutions sur le "comment j'aurai du
organiser les dossiers" et/ou "pourquoi 3 et pas 2", est-ce qu'on pourrai
ne pas ce perdre et revenir au sujet principal ?
Pour ne pas *se* perdre et revenir au sujet de l'historique cassé, Charles postait un lien qui pourrait t'être utile :
On y trouve la méthode pour déplacer un dossier sans perdre l'historique, et marcimat y propose même un méthode pour le faire en un seul commmit :
Certes sauf que je vois mal comment corriger maintenant que le mal est
fait.
D'autant que j'ai utiliser "svn mv" qui aurait dû garder l'historique.
Il ne l'a pas fait, et je ne sais pas pourquoi.
Si quelqu'un sais quel magie noir il faut utiliser pour que cela
fonctionne vraiment et comment la mettre en place en l'état actuel des
choses...
Bruno Bergot <brunobergot@gmail.com> writes:
Le 30/01/2018 à 13:50, Debondt Didier a écrit:
Hello,
Aussi passionnante que soit ces discutions sur le "comment j'aurai du
organiser les dossiers" et/ou "pourquoi 3 et pas 2", est-ce qu'on pourrai
ne pas ce perdre et revenir au sujet principal ?
Pour ne pas *se* perdre et revenir au sujet de l'historique cassé,
Charles postait un lien qui pourrait t'être utile :
Certes sauf que je vois mal comment corriger maintenant que le mal est
fait.
J'ai bien peur que la seule solution soit le revert.
D'autant que j'ai utiliser "svn mv" qui aurait dû garder l'historique.
Il ne l'a pas fait, et je ne sais pas pourquoi.
Si tu avais bien utilisé svn mv comme indiqué dans mon article, tu n'aurais certainement pas perdu l'historique.
Si quelqu'un sais quel magie noir il faut utiliser pour que cela
fonctionne vraiment et comment la mettre en place en l'état actuel des
choses...
Comme je le disais plus haut, possible qu'un revert nous permette de rétablir l'historique, car pour l'instant il est cassé aussi bien sur le trunk que sur ta branche, et ça ne ferait certainement pas plaisir à feu toggg :\
