hi,
I am not against the principle of freezing a version, but why should we
have a clear roadmap with clearly defined development goals, which is
not really the case. Everyone does it on its side soup without any
consultation and suddenly we are never synchronous on the status of
each. We must be more diligent in using at least the management tasks in
doliforge. (me included) :-)
je ne suis pas contre le principe de figer une version, mais pour ça il
faudrait qu'on ai une roadmap clairement défini avec des objectifs de
développement clairement défini, ce qui n'est pas vraiment le cas
actuellement. Chacun fait ça soupe de son côté sans aucune concertation
et du coup nous ne sommes jamais synchrone sur l'état d'avancement de
chacun. Il faut qu'on soit plus assidu à utiliser au moins la gestion
des tâches dans doliforge. (moi le premier) :-)
Le 13/04/12 01:05, Sasa Ostrouska a écrit :
> Hi, I would say, that beta , RC and other names are used, as Eldy said,
> exactly to make a point from where a maintainer of the code decides that
> the code is
> becoming stable and bug free with the features it has. This explains
> exactly that adding new features is not allowed, and contradictory.
>
> VCS (Version Control systems) were invented exactly to simplify this
> process. This is whay they permit you to branch and tag code.
>
> So in my opinion alpha, beta and any other code tag should never receive
> new features. If it receives new features it is not alpha or beta or
> release candidate , but its development code.
>
> Rgds
> Saxa
>
> On Wed, Apr 11, 2012 at 11:14 AM, Cyrille de Lambert
> <address@hidden <mailto:address@hidden>>
> wrote:
>
> 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,
>>
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/
---------------------------------------------------------
_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev