On Sep 6, 2013, at 9:33 AM, Goubier Thierry <[email protected]> wrote:
> > > Le 05/09/2013 22:04, Stéphane Ducasse a écrit : >>>>> >>>> >>>> Who says that? We always said that we will back-port all imported fixes to >>>> 2.0. We will not back-port *everything*, especially >>>> not improvements that are not fixes, because then there would be no >>>> difference between Pharo3 and Pharo2 (and these >>>> tend to introduce new problems, making it very hard to stabilize). >>> >>> Are you afraid that by improving Pharo2 on a production-level, you would >>> remove incentives to move to pharo3? >> >> No just that we do not want to stop 3.0. Because changing 20 will introduce >> bug we are 100% convinced about that. >> The system is still not in a situation where changes are simple and with >> limited impact. > > As you said, 2.0 has bugs. Look, at one point, we even had a 2.5 in the works > (who did it, already? Sean? Sven?). no, we don't bah, we have 2S, which would be the "2.5" if you want. Also Sean made something to install some new issues from 3 in the older version... but that's not a new version, is just that Sean wanted to have some things immediately :) > > >>>> But it is clear that this is a fine line: one persons fix is the others >>>> persons bug, so we tend to be conservative. >>>> But nevertheless, all show-stopping bugs should be fixed. >>> >>> I'm OK with that. It's just that I'm updating a fix for a bug on both >>> Pharo2 and Pharo3 by myself just to be able to open a file browser and get >>> correct file permissions. >>> >>> I'm also unable to be sympathetic to a situation where I have two versions >>> of a code just because when deprecating ensureDeleted in 3.0, nobody >>> thought usefull to backport ensureDelete so that we could ensure that code >>> using ensureDelete could work on both versions. >> >> This is simple nobody told us. Open an issue and tag it 20 + code and it >> will be in the batch of 2.0. > > I'll do. > >>> I also understand that you need 3.0 to be declared unstable to be able to >>> make the necessary improvements in it. >>> >>> But this has the following consequences for non-core development, say SmaCC >>> for example: 2.0 is the platform for unstable, >> No it is not 2.0 is stable. We have production code with it. Now it is not >> bug free and 1.4 is far from bug free. It is just that you do not get >> touched by these bugs. >> >>> 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't >>> develop until it has reached a sufficient level of maturity. >>> I will do things on SmaCC in the near future, but not on 3.0. >> >> this is a mistake to me. Because if you discover bugs we will fix them. Now >> if you wait one year to move to 3.0 we will be working on 4.0 and >> the story will never ends. > > And there I can only disagree with you. > > * I do want you on an unstable Pharo, something moving and changing fast to > be able to aim for the sky and bring me a smile for what tomorrow will bring > me... > * I want a stable Pharo, because this is where my work takes place, and there > bugs should really get fixed... > * I want old stable Pharo(s), because, if my work goes into production, it > may stay there for years. > * And I want a nice path from today's stable to the next stable to be able to > port my code as soon as possible (for example, we did OSProcess this time... > but I believe there is a chance this work will have to be done again before > 3.0 is released ;)) > > Insisting for 3.0 based developpement means I require additional code to the > core: OSProcess, FileTree, GitFileTree, SmaCC... Maintaing those for 3.0 is > extremely difficult, with very disruptive changes coming often. And one get > tired of complaining; at one point I just open a bugfix, create a slice and > add a line to my image building makefiles to load the bugfix because > bickering about whether it should be integrated or not isn't worth the time > spent on it. > > So my suggestion would be more like this: 2.0 stable, 3.0 beta (freeze), and > 4.0 alpha (experimental), and maybe different teams for handling each of > those (and releases on a six months basis?). that's not possible because that implies manpower that we do not have, and thats, so far, a reality that will not change in the near future. So, what we have is: stable branch (now 2.0), unstable branch (now 3.0), and when we release pharo3, that will become stable and the next branch will be unstable, while 2.0 will fade out. the effort of maintaining multiple versions is exponential, not linear. > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des Systèmes Temps Réel Embarqués > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >
