Hi Marcus, There is no release yet! >
How often are you planning to do a release? I suppose the next release is the reached milestones for 1.1? > > > everything that worked before should still work perfectly. The new stuff > being added are first buggy; seems normal to me. But if the new stuff is > breaking old, working stuff, and we only notice it after a month; then it > will take us a lot of time, debugging the issues, investigating them; time > we should spent instead on adding new stuff. > > The old stuff is *very very bad*. It needs to be fixed. This is when stuff > breaks. > Absolutely. > > > > > > |I've done a number of production applications in Squeak and we always > > |used the stable version for that. Or, in case we really needed > something > > |from the trunk version, we only updated occasionally when we were sure > > |it had reached a somewhat stable plateau. > > > > You're correct on this one, however in this case, Pharo IS the production > work. It is Pharo itself we are also developing. And since it is > development, I think we should make sure the quality keeps up at a highest > level possible, even if modifying it. > > > > I don't mean to criticize, I love the opensource initiative that Pharo > is, I'm just trying to help Pharo further. > > Any other thoughts on this? > > > > I can not work on a system where every change on the unstable branch is > garanteed to not break anything. > That is because I don't know how this is possible to do. > > Marcus Allow me to explain why I have such strong beliefs about this. On my firm, we are using some techniques to enable that. On one project they are releasing new functionality every two weeks. How they do that is as following. These 2 weeks releases are incremental changes to a already running production system. They take a limited set of functionality that can be developed in say just over a week. Nightly builds are deployed on test servers. After a day or three development, parts of the developed functionality can already be tested by the proxy. After six or seven days of development, the core dev is done, and they focus on fixing the errors. After a day or two more the whole stuff is developed, tested en ready for production. The main reason why this works pretty well, is that they take small steps. They set a target to develop a limited set of functionality, and commit to it as a team. Furthermore they use extensive testing. They write unit tests for every line of code written and also write integration tests. The product developed is a web application. They use a rich domain and a sql db. They write extensive unit tests for the functionality of the domain; write one integration test if the domain object can be persisted correctly, and write also a limited set of gui tests using selenium, to verify if the gui is working correctly. The amount of unit tests is very high, the amount of integration tests / gui tests much lower. The unit tests serve to test the core behaviour, the other tests more or less if 'everything is wired correctly'. Working like this, they have a high confidence in the code; they get immediate feedback if something broke: so they can fix these errors quickly. The small steps combined with the extensive testing is what enables us to create these short releases. If they would try to integrate a lot of changes at once, it would take them a lot longer to make that stable. We call every build, in which all tests run, 'a potential shippable product'. I think that in Pharo most of the tests are unit tests. Please correct if I'm wrong, don't know it well enough yet. Each package is perfectly unit tested. However the dev image which tries to integrate different packages is, I think, lacking integration tests to see if they properly work together. Take the example I gave. Refactoring tools work very well, are nicely unit tested; however combined with the Package browser it did not work. The net result of it is that it does not work. Now I off course understand that, since Pharo is opensource and community driven, it will be a lot harder to achieve a short release period than doing this on my firm, full time developing on the product. These are just my views I use in my day 2 day work. Kind Regards, Bart -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein Gravitation is not responsible for people falling in love. - Albert Einstein
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
