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,