Eric a écrit:

Ah? Du Rap? T'es sûr?

Ben, le texte de Whiler sonnait bien, là... mais je sens comme une certaine réticence, dans ta réponse ??...

Eric a écrit:

Non, parce que moi, je suis plutôt "bandes de chevelus, tatoués, hurlants dans le micro et grattant frénétiquement une guitar électrique au son tellement saturé et boosté que çà décolle le papier peint de tout un immeuble de 3 étages".

Je vois :-)) , j'ai connu ! (Enfin, pas les travaux dans un immeuble de trois étages... bravo dis donc !! ^^)

Bon, ben notre vocation musicale semble compromise alors :-/ ...

Revenons-en donc à l'informatique... je suis de retour à la maison, j'espère pouvoir avancer un peu [Bugtracker] ticket 2100...

(Quel subtile sortie du HS, n'est-ce pas ?? ^^ ...)

Ouille ouille ouille, déterrage de vieux topic...

À l'occasion de [Forum, post 193932 by julien1311 in topic 20044] [Plugin] LCAS - Insensibilité aux accents et à la casse, j'ai repéré le [Bugtracker] ticket 2757. Comme j'ai décidé de me remettre à Piwigo sérieusement (si si...), et surtout que ce bug était vraiment très simple à résoudre, j'ai effectué la correction et voulu livrer... oui mais sur LCAS on est organisé en branche, tag, trunk... et chuis pas habitué...

Alors bon j'ai créé le tag 2.2.3, et ai modifié le trunk ; jusque là je pense que j'ai pas fait trop de bêtises... mais pour le dossier "branch", faut-il faire quelque chose ? Son contenu semble pas mal différer de la version trunk...

Petite explication rapide (pas trop de temps libre en ce moment...) - Analogie avec un arbre :
- Le Trunk représente les racines de l'arbre. C'est le dossier de travail partagé sur lequel on "commit" (via SVN) toutes les modifications de code apportées sur le projet par chaque développeur. Cà, tout le monde l'a compris, je pense. ;-)

- Les Tags représentent les feuilles de l'arbre et donc chaque release (code stabilisé) du projet qui seront ensuite publiées dans PEM. Là aussi, facile.

- Les feuilles ont besoin de branches (branch) pour s'accrocher. Logiquement, dans le cadre d'un plugin, on devrait trouver une branche par groupe de compatibilité avec une version donnée de Piwigo. Par exemple, une branche 2.4 regroupera toutes les modifs de code du trunk compatibles avec Piwigo 2.4.x et on génèrera les tags 2.4.x du plugin depuis cette branche pour la version compatible de Piwigo.

Cette structure de gestion de projet est valable si le plugin en question évolue de manière différente en fonction de la version de Piwigo. Certaines fonctions d'un plugin peuvent ne pas fonctionner sur une version x de Piwigo pour des raisons techniques alors qu'elles seraient compatibles avec la version x+1.

Mais, avec le recul, je m'aperçois qu'il est rare qu'une fonctionnalité ne soit pas entièrement portée entre les versions de Piwigo. Dans le cadre de LCAS, on peut donc se passer de cette structure en supprimant les branches. On peut aussi envisager de ne conserver que le trunk qui servira de référence pour la publication des releases dans PEM mais il faut être certain de la stabilité du code. Pas facile lorsqu'il y a plusieurs développeurs sur un même projet.

Bref, c'est une question d'organisation. Il faut choisir la moins contraignante et la plus facile à gérer. Luc, à toi de voir ;-)