Le 27/02/2019 à 08:52, Eric Lupinacci a écrit :
Hello,
Le mer. 27 févr. 2019 à 07:35, Mist. GraphX <arnaud.berard@mister-graphx.com <mailto:arnaud.berard@mister-graphx.com>> a écrit :
De mon avis , une branche justement peut et souvent n'a rien a
voir au
niveau developpement (hormis le concept de base , le sujet : d'ou
le mm
dossier ), une branche peut ne pas utiliser les memes libs, ne pas
utiliser le meme code, et si on veut la distribuer en paquet il faut
bien qu'elle ai un prefix différent je pense.
ça va être le cas par exemple sur logo_auto
Ah ben non surtout pas !
Dans ce cas ce n'est plus le même plugin.
La plupart des plugins ont des branches et toujours le même plugin justement pour repérer qu'on parle du même plugin.
je me suis peut être mal exprimé (ou éxagéré le rien a voir ^^, on connait des projets open-source qui ont commencé par être une branche avant d'entamer une vie a part), je pense que l'on parle de projet pour ce qui est du dossier principal sur la zone,
ensuite un projet peut avoir plusieurs visions qui sont travaillé différements pour des raisons x ou y (compat php, besoin utilisateur)
le besoin final dans notre cas étant un ou plusieurs paquets que l'on veut mettre a dispo
la différence de prefix (en gardant biensur un reference a l'original prefix_BRANCHE) peut se justifier pour signaler et eviter une confusion au niveau du paquet, une erreur d'activation auto (ex le skel necessite et ne définie pas la version la plus haute du plugin)… j'admet qu'on sort du schéma semver qui suit un cycle de version…
ça permet de distribuer via svp des branches différentes (expérimentales, stable, alpha) sans ambiguité possible je trouve (mais c'est un peut un hack au sens semver … ex sur github quand tu release tu peut pas sauter un numéro ^^ il veut pas).
Quid du coup de comment on fait (dans l'idéal :p) pour distribuer les paquets de deux branches différentes d'un plugin/projet de manière sure, géré par svp, gérable depuis le skel, etc … sinon ?
juste avec le numéro de X ? je me dis, et c'est ptett faux, que un skel ou plugin (j'admet c'est ça faute) qui necessite [1.0.1;[ installera la version la plus haute, et du coup pas forcément celle voulue
- le trnk propose une version géré par modèles (c'est la version
historique, stable, zippé)
C'est pas la pratique conseillée il me semble.
Le trunk est plutôt la version en cours de développement quand elle existe.
Après c'est exact que ça dépend de comment on est arrivé à créer trunk et branches.
oui, j'ai toujours le sentiment (sur la zone), qu il y'a mélange entre le besoin de suivi du code, et le besoin final de génération de paquets et c'est vrai que du coup c'est intimement lié dans ce cas précis
souvent sur la zone le paquet est généré depuis le trunk ou le dossier de travail, c'est plus simple pour le dev mais plus "risqué" pour les paquets, c'est un peut historique, et déjà presque tout les dossiers ont un trunk y'a eut du boulot/chemin de fait, c'est beau ( au passage 
applause ),
les dépot externals, eux sont obligés de passer par un tag/release, pour générer le paquet, le master peut être completement instable (une release/tag aussi mais ça c'est une autre histoire ^^) , … c'est un peut identique je trouve avec composer de ce que j'en utilise ou sait , c'est rare que la lib soit installé depuis le master/trunk …
Bonne journée @++
Arnaud
