dolibarr-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dolibarr-dev] 3.2 frozen for any new features


From: Régis Houssin
Subject: Re: [Dolibarr-dev] 3.2 frozen for any new features
Date: Wed, 11 Apr 2012 15:55:35 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1

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,
-- 
Régis Houssin
---------------------------------------------------------
Cap-Networks
Cidex 1130
34, route de Gigny
71240 MARNAY
FRANCE
VoIP: +33 1 83 62 40 03
GSM: +33 6 33 02 07 97
Web: http://www.cap-networks.com/
Email: address@hidden

Dolibarr developer: address@hidden
Web Portal: http://www.dolibarr.fr/
SaaS offers: http://www.dolibox.fr/
Shop: http://www.dolistore.com/
Development platform: https://doliforge.org/
---------------------------------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]