Gestion des versions de skin


#1

Bonjour,

Je travaille actuellement sur des skins. Je ne modifie que le dernier chiffre (le troisième) de version. Quand j’installe une nouvelle version du skin dans l’entrepôt, il s’installe à côté de la version précédente. Je doit supprimer la version précédente et puis passer dans chaque atelier pour y activer le nouveau skin, ce qui n’est pas top.
Est-ce que je procède bien comme il faut ? N’y aurait-il pas moyen que ce soit autrement (le skin de la version précédente est remplacé par la nouvelle au moins quand la différence se situe dans le troisième niveau de version)? Car cette situation n’encourage pas à utiliser les versions…


#2

Quelqu’un ? une réponse ?


#3

Bonjour,

La réponse a votre question est dans le livre de Stéphane Crozat : Scenari - La chaîne éditoriale libre à la page 149.

Livre que je vous conseille d’acheter même s’il date de 2007. Il y a tous les concepts de base pour bien utiliser les chaînes éditoriales Scenari, sinon il y a la documentation en ligne ici ou

Un petit extrait du livre en tentant de respecter le droit d’auteur :

Gestion des versions de modèle
Un modèle est associé à trois numéros de version :
• mineur (minor) ;
• moyenne (medium) ;
• majeure (major).
Si vous changez le numéro de version mineur ou si vous ne changez pas
le numéro de version, l’installation du wsppack dans SCENARIchain
remplace l’ancien modèle s’il existait.
Au contraire, si vous changez le numéro de version moyenne ou majeur,
le nouveau wsppack installé sera considéré comme un modèle différent.
Vous devrez donc créer un autre atelier lié à ce modèle pour l’utiliser (et
donc copier les contenus dont vous disposiez dans l’ancien atelier).

et dans la marge :

MÉTHODE Changement de version mineure
Il est conseillé, lorsque vous faites une modifica-
tion de style de votre modèle, de changer son
numéro de version mineur, les modifications
moyennes et majeures étant plutôt réservées à des
changements plus profonds.

Comprendre qu’un SKINPACK (fichier .skinpack) se gère de la même manière qu’un WSPPACK (fichier .wsppack). L’extrait concernait Scenari Builder puisque historiquement les SKINS étaient modifiés avec ce logiciel, Scenari Styler étant apparu plus récemment.

Personnellement j’utilise les deux logiciels en fonction des chaînes éditoriales, certaines acceptent des personnalisations sous forme d’extension wsppack d’autres comme Canoprof ne le permettent pas.

En fonction de vos compétences, Scenari Builder peut vous permettre d’adapter plus en profondeur les modèles en ajoutant par exemple dans un .uitemplate un lien vers un favicon, un lien vers une lib css ou une lib javascript comme jquery simplifiant le chargement des libs plutôt que de bricoler un loader, et bien plus si vous voulez vous créer votre propre chaîne éditoriale.

Pour finir, c’est la rentrée nous serons peut-être plus nombreux à pouvoir vous répondre donc n’hésitez pas à revenir sur le forum si des points restent encore obscures pour vous.

Cdt

Xa


#4

Bonjour Etienne,

Effectivement, ce comportement est un choix initial (2011) qui est beaucoup trop rigide, et pas en phase avec la règle adoptée pour le reste des briques applicatives scenari (pack, app, …) et rappelée ci-dessus par @xavier_a.

Ce problème a déjà été remonté, et corrigé dans la branche 5.0 uniquement, une modification de cette règle ne pouvant avoir lieu sur une application déjà en production pour éviter les effets de bord (pas de modification en 4.2).

Bon WE

Antoine

Kelis


#5

D’ailleurs Stéphane vient de sortir un nouveau livre… https://framabook.org/traces/
Pas encore lu, mais il me semble qu’il parle tout de même un peu moins de Scenari :slight_smile:


#6

Bonjour,

Merci de vos réponses !
Donc ce que je souhaite sera bientôt en place. Bravo :sunny:


#7

Bonjour,

Je reviens sur la question parce qu’il me semble qu’il peut y avoir un intérêt à ne pas écraser une version précédente d’un SKINPACK.

Si je résume, pour l’instant l’installation d’une version plus récente d’un SKINPACK (ex: v0.6.66) n’écrase pas une version plus ancienne (ex: v0.6.65) ce qui oblige à supprimer les versions précédentes lorsque le numéro de version est incrémenté.

Oui mais voilà tout le monde n’utilise pas git ou svn, c’est à dire un logiciel de gestion de versions et la loi de Murphy nous rappelle que les erreurs ne sont pas aussi rares qu’on le voudrait lorsqu’on écrit du code.

En effet, il est parfois utile de pouvoir revenir en arrière ou de retrouver un code plus ancien pour corriger son erreur et les anciens SKINPACK sont situés dans le profil de l’application ( *.default/srv/emdFix/skins/) ce qui me semble pratique pour l’instant.

Selon moi l’évolution envisagée va dans le bon sens mais il faudrait peut-être conserver dans l’arborescence un backup des x derniers SKINPACK avant la mise à jour.

En mode client-serveur, j’image que l’admin est un pro, il fait régulièrement les sauvegardes et il les stocke “ailleurs” ce qui lui permettra de retrouver d’anciennes versions des SKINPACK pour le dev (/var/lib/scenariserver*/addons/skins).

Cdt

Xa