Pour info, il y a pas mal de bugs à corriger (version 3.1) ->
exemple sur les filtres (commande fournisseur entre autre) qui se
réinitialisent alors que ce ne devrait pas être le cas.
Vu qu'on est (encore) complètement perdu avec GIT, ce sont des
choses qu'on avait corrigé mais qu'on a surement perdu en cours de
route.
Je vais faire un tours de cette version bêta pour voir ce qui va ou
pas.
Cyrille
Le 11/04/2012 16:03, Laurent Destailleur (eldy) a écrit :
Ajouter
des fonctionnalités et faire des comit pour en compléter d'autres
reviens au meme, on crée de l'instabilité sur ce qui a été validé
comme stable.
Si des commits enlevés rendent bancales des choses, c'est qu'il y
avait bug avant d'etre enlevés et la beta est la pour les
corriger. Et si cela corrigent ces bugs, les changement seront
acceptés, donc pas de problèmes.
J'accepte les bleus au visage. L'interet des utilisateurs étant
prioritaire sur ma santé ou sur l'interet des développeurs.
:-)
Le 11/04/2012 15:55, Régis Houssin a écrit :
je parle en french car j'ai pas le temps
de googliser
je ne parlais pas de rajouter des fonctionnalités mais de
compléter ce
qui était en train de se faire, car certains des commits que tu
as
enlevé va rendre bancale les devs en cours, ce qui va encore
rendre la
3.2 non finalisée, et des gueulards et des énervements et des
coups de
poings dans la gueule et des bleus au visage ;-))
Le 11/04/12 15:47, Laurent Destailleur (eldy) a écrit :
Le 11/04/2012 14:55, Régis Houssin a écrit :
but we will still end up in the same
case, the 3.2 become obsolete even
before being output :-)
Wrong. Adding new features in a release means restart from the
end the
beta and having beta delay that last 8 month (like it was for
3.1).
Saying we can't release because it miss feature is not a good
way of
thinking. It means, Dolibarr should not have been released at
all even
in version 1 and should not be released even in 5 years.
Imagine a feature is rejected because it was done just the day
after the
froze, at t=0 (+1 day). This feature will be included in next
beta, so
only two month after at t=+2 month, so can be released at
t=+6. This
means the feature you say it miss, will be available at t+4
instead of
t+8 (if it is t+8, it might be t+12 if we keep add changes
into beta).
And t+4 is better than t+8 !
We saved 4 month to have new features. So, adding features in
a beta is
a lost of time for everybody and it is the worst way to have
missing
feature in current stable version because the complete version
that
include it can't be release before several month. Users must
not wait so
long, that's why we must end with changes into a beta branch,
just to
have more feature, faster !
Don't forget this : There is commit every day to add features
and
whatever you do, you will always have missing features. If we
don't make
any stop, we will never make release or we will need to wait 8
month
like we did for 3.1 to have a beta stable (and it should be
more if i
didn't stopped adding features into beta, and there was still
lot of
bug, curiously, most of them was bugs introduced by change of
last
minutes). Making a version stable (that is most important that
having a
feature) consumes most of time of core team that make the beta
tests,
time wasted.
Features can come two times faster if we respect best
practices
seriously, and version will be less obsolete when it will be
released.
Le 11/04/12 12:41, Laurent Destailleur
(eldy) a écrit :
Sorry.
A beta is a beta.
Adding something else means all time spent by tester to
guarante that
everything is stable must be started again.
We can't always add new features or add complement on a
frozen version.
Any change, even minor that is a new feature breaks
stability.
Just an example, 60% of time I spent to make beta 3.0 and
3.1 stable was
spent to restore stability by forbidden adding feature or
architecture
change. This is not acceptable. This rate should be 0%.
Any change that are not fix will be discarded if it is not
to fix a bug,
translation or documentation.
Le 11/04/2012 12:32, Régis Houssin a écrit :
yes but no, they are commits that
complement the current dev, we'll
still end up with 3.2 sloppy, they should be able to
include minor
additions in this 3.2
Le 11/04/12 11:00, Laurent Destailleur (eldy) a écrit :
Hi Dolibarr developers.
I revert some changes into the 3.2 branch because they
were
introducing
new features.
Absolutely no change must be done into the 3.2 branch,
except if a bug
is found and change must fix only the found bug.
Code normalizing and new features must be push using
github into the
develop branch only.
Cordialement,
Cordialement,
Cordialement,