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 < [email protected]> 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, > > > > -- > [image: AUGURIA] > Cyrille de Lambert [email protected] > 9, rue Alfred Kastler > BP 50752 > 44307 NANTES CEDEX 3 Tél : +33 (0) 2 51 13 50 12 > Mobile :+33 (0) 6 29 41 81 22 > Fax : +33 (0) 2 51 13 52 88 > http://www.auguria.net > > _______________________________________________ > Dolibarr-dev mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > >
<<AUGURIA.jpg>>
_______________________________________________ Dolibarr-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
