Attention, préférez les version datées plutôt que numérotées (la 1.4d4
ne fonctionne pas, par exemple).
En toute logique ça devrait être l'inverse (sinon la numérotation
ne sert pas à grand'chose ;-)).
Yup. Un de vous fais une d5?
Attention, préférez les version datées plutôt que numérotées (la
1.4d4 ne fonctionne pas, par exemple).En toute logique ça devrait être l'inverse (sinon la numérotation ne
sert pas à grand'chose ;-)).
Bin non, une numérotation indique un jalon, c'est forcément moins à
jour qu'une version à dernière date !
-Nicolas
> Attention, préférez les version datées plutôt que numérotées (la 1.4d4
> ne fonctionne pas, par exemple).En toute logique ça devrait être l'inverse (sinon la numérotation
ne sert pas à grand'chose ;-)).
Pourquoi dis-tu ça ? La numérotation sert à marquer des repères après de
grosses modifs, et les versiosn datées sont plus proches de la CVS. Ni l'un
ni l'autre ne sont censés fonctionner sans bug.
-- Fil
En général, on ne pose un jalon que lorsqu'on a raisonnablement confiance
en la version actuelle. Si on trouve que la version actuelle est plus stable
que le dernier jalon posé, on repose un jalon. Du coup, la qualité des
versions "jalon" tend vers le maximum de stabilité.
Sam
En général, on ne pose un jalon que lorsqu'on a raisonnablement
confiance en la version actuelle.
Pour le majeur et le mineur des versions stables, oui, mais pas en
beta sur des versions de développement où ce sont surtout les
modifications fonctionnelles qu'on indique.
-Nicolas
Alors je ne vois pas l'intérêt de continuer à poser des jalons maintenant
qu'on a un bouton "create tarball" (ou similaire) sur le CVS web. Il faudrait
mettre un lien dessus directement.
Plus sérieusement, un jour, il va falloir faire des releases. Si on incite
les gens à tester la dernière version plutôt que des jalons qu'on a choisis,
ils risquent de se retrouver avec des bugs majeurs qui viennent tout juste
d'être introduis, je ne pense pas que ça soit une bonne chose.
En fait, cela signifie que les développeurs ne doivent pas prendre le risque
de casser quoi que ce soit dans le dépôt CVS, notamment plus faire de
changements importants, car le CVS est sensé être la version la plus stable.
Ce mode de fonctionnement, dans lequel les développeurs ne choisissent pas
quelle version ils demandent à faire tester, n'incite pas à mettre à jour
son serveur pour faire les tests.
Sam
@ Nicolas Hoizey <nhoizey@phpheaven.net> :
> En général, on ne pose un jalon que lorsqu'on a raisonnablement
> confiance en la version actuelle.Pour le majeur et le mineur des versions stables, oui, mais pas en
beta sur des versions de développement où ce sont surtout les
modifications fonctionnelles qu'on indique.
De toutes façons sur spip on n'en fait qu'à notre tête 
Enfin, pour vous faire plaisir on va passer en 1.4d5. C'est cool non ?
-- Fil
De toutes façons sur spip on n'en fait qu'à notre tête
Pas tant que ça, vous avez fini par accepter de bosser avec un serveur
CVS, c'est énorme !!! 
Enfin, pour vous faire plaisir on va passer en 1.4d5. C'est cool
non ?
Ca ne changera rien pour moi, j'ai plusieurs sites mis à jour direct
depuis le CVS, je dois être dingue ...
-Nicolas
Bin non, une numérotation indique un jalon, c'est forcément moins à
jour qu'une version à dernière date !
Mais plus stable. Exemple : Apache : les versions beta sont plus stables
que les "nightly builds".
D'ailleurs, les versions officielles sont encore moins à jour que les
betas, et encore plus stables 
Quelqu'un veut faire un scrabble ?
En réponse à Fil <fil@rezo.net>:
@ Nicolas Hoizey <nhoizey@phpheaven.net> :
> > En général, on ne pose un jalon que lorsqu'on a raisonnablement
> > confiance en la version actuelle.
>
> Pour le majeur et le mineur des versions stables, oui, mais pas en
> beta sur des versions de développement où ce sont surtout les
> modifications fonctionnelles qu'on indique.De toutes façons sur spip on n'en fait qu'à notre tête
faut pas dire ça. Vous avez quand même accepter de passer sous CVS. Alors
maintenant un peu plus de rigueur sur les jalon et se sera presque parfait
PS le parfait n'existant pas en informatique je ne l'attandrai pas...
Enfin, pour vous faire plaisir on va passer en 1.4d5. C'est cool non ?
-- Fil
_______________________________________________
spip-dev@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-devFrom fil@miel.brainstorm.fr Wed Jul 17 15:31:17 2002
Return-Path: <fil@miel.brainstorm.fr>
Received: by miel.brainstorm.fr (Postfix, from userid 1001)
id A375D1C690; Wed, 17 Jul 2002 15:31:17 +0200 (CEST)
Quelqu'un veut faire un scrabble ?
Raaah, arrête, tu me tentes grave !!! 
-Nicolas
Mais plus stable. Exemple : Apache : les versions beta sont plus stables
que les "nightly builds".
Quelqu'un a une définition de "stable" ? Pour ce que j'en comprends, ce
terme ne s'applique pas à une version mais à un processus.
Une version donnée n'est pas stable ni instable, elle est bugguée ou pas
(pas trop). Une branche du développement peut être "stable" (une version
1.3.2, par exemple, à laquelle on ne touchera que si un gros trou de
sécurité est découvert), ou "instable" (la 1.4, qui merde par moments, où
des trucs sont ajoutés puis retirés puis rajoutés, etc).
-- Fil
Une branche du développement peut être "stable" (une version 1.3.2,
par exemple, à laquelle on ne touchera que si un gros trou de
sécurité est découvert), ou "instable" (la 1.4, qui merde par
moments, où des trucs sont ajoutés puis retirés puis rajoutés, etc).
En effet, et il faudrait pouvoir gérer les deux dans le CVS, en
adoptant par exemple une numérotation à la noyau de Linux ...
-Nicolas
Une version donnée n'est pas stable ni instable, elle est bugguée ou
pas (pas trop).
Ca doit être un anglicisme ou un nerdicisme, mais "stable" dans le
cas d'une version veut dire effectivement non buggée. Pareil pour
un système d'exploitation (si c'est stable, ça ne passe pas son
temps à planter).
Une branche du développement peut être "stable" (une version 1.3.2,
par exemple, à laquelle on ne touchera que si un gros trou de
sécurité est découvert), ou "instable" (la 1.4, qui merde par
moments, où des trucs sont ajoutés puis retirés puis rajoutés, etc).En effet, et il faudrait pouvoir gérer les deux dans le CVS, en
adoptant par exemple une numérotation à la noyau de Linux ...
Mouais mais alors déjà qu'on arrive à écraser des modifs, alors
gérer plusieurs branches.... En plus si le client graphique n'est
pas bien foutu dans la gestion des branches, c'est la cata
Ca doit être un anglicisme ou un nerdicisme, mais "stable" dans le
cas d'une version veut dire effectivement non buggée. Pareil pour
un système d'exploitation (si c'est stable, ça ne passe pas son
temps à planter).
Je ne vois pas le rapport entre les deux concepts. Sinon qu'en général une
branche "stable" a dû se stabiliser sur une version pas trop bugguée, sinon
c'est du foutage de gueule.
-- Fil
Mouais mais alors déjà qu'on arrive à écraser des modifs, alors
gérer plusieurs branches.... En plus si le client graphique n'est
pas bien foutu dans la gestion des branches, c'est la cata
Le plus simple est de gérer deux projets, et non deux branches d'un
même projet. C'est ce que nous fais(i)ons pour phpMyChat.
-Nicolas
Je ne vois pas le rapport entre les deux concepts.
Bon c'est très simple : quand un logiciel est "stable", il est capable
de tourner comme une horloge. Quand il est "instable", il plante à
tout va. En tout état de cause quand quelqu'un te demande si un soft est
"stable", il te demande s'il est bien débuggé, pas si les fonctionnalités
sont figées.... (ou alors c'est un extra-terrestre qui veut jouer avec
l'API, sachant que SPIP n'en a pas). La version "stable" de Debian, c'est
une version qui marche bien. Par conséquent, il est probable qu'elle ait
également été figée pour un certain temps, puisque ça vaut le coup de
conserver en évidence une version qui marche. Mais c'est un effet de bord.
De toute façon, c'est une terminologie, suffit de l'accepter
(ou de jouer au scrabble ;-)).
Je ne vois pas le rapport entre les deux concepts. Sinon qu'en
général une branche "stable" a dû se stabiliser sur une version pas
trop bugguée, sinon c'est du foutage de gueule.
Oui, c'est ça.
On a une x.y non stable en cours de développement, et dès qu'elle se
stabilise suffisemment, c'est à dire qu'elle semble exploitable, on en
fait une x.(y+1) ou une (x+1).0 et on continue les développements sur
une x.(y+2) ou une (x+1).1 ...
On incrémente x si l'API change, y si seul le fonctionnel change.
Pour une version x.y.z, x est donc en gros la version d'API, y la
version fonctionnelle (pair pour une stable, impair en dev), et z des
corrections de bugs sur une stable ou des modifs sur une dev.
-Nicolas