[Moose-dev] About Metacello and the Moose process

Unfortunately, there have been too many threads this morning *About Metacello* Well Metacello is still in beta, so good news is that we can make it better. Problem is that it can do a lot of things about which we (I) dont a clear picture for now, it requires some usage and conventions, and myself I'm still quite unsure about how Metacello manages nested configuration (for example right now, when I perform a ConfigurationOfMoose updateDefault, it does not update the nested configurations. I am not sure but I think it should) Suggestions: 1) have better names loadLast -> loadDevVersion or loadVeryLast loadLatest -> loadStableVersion or loadLastStable (those 2 are really annoying) Also the names in the OB commands could be better and reflect the current conventions: Save project -> save configuration update project -> update configuration Update Package Methods -> update current version??? Now, when I do a "Current Project Version" on any ConfigurationOf, it does not work except for the one with Metacello. I dont know, maybe the configurations do not respect some rules? It's annoying because it breaks the above tools. 2) refactor the documentation When I started with Metacello 3 months ago it was easy because there was one recent post describing the things. Now three months later this is a problem because things have changed a lot but this post is still the first hit in google "metacello" http://gemstonesoup.wordpress.com/2009/08/25/metacello-package-management-f… Now if you try to follow links there is this post and then this post http://gemstonesoup.wordpress.com/2009/10/14/a-shiny-new-api-for-metacello/ http://gemstonesoup.wordpress.com/2009/11/16/metacello-1-0-beta-14-released/ Finally it appears that http://code.google.com/p/metacello/w/list is now the source for documentation. There is the API reference for declaration, description of OBCommands,... Unfortunately it lacks something about how to play with last/latest versions with the API. - if I go to the tutorial, it just refers to the embedded tutorial in the code and I dont want to load the tutorial each time I need some documentation So please Dale, can you put a few items about things such as ConfigurationOfXXX project lastVersion, how to manipulate groups, things discussed with Lukas? 3) Good tool for managing configuration, saving projects... There is a small browser in GLMSmalltalkExamples>>metacelloBrowser, maybe somebody can start to enhance it to display version and perform commands. *About the Moose process* I dont think the Pharo process and the Moose process compare. The Pharo process is about integrating fixes from packages which are supposed to do one and only one thing, and do it well and is tested. The Moose process is about developers making incremental changes to the code base so that they can work and share it immediately. Which means it can break other things. Now I'm pretty sure I dont want a release every time someone commits a package in Moose, because I'm pretty sure this someone didn't run all the tests before committing. So making a release for each new commit makes no sense for me. We dont integrate changes, we just merge when there are some divergent branches. That's why we are always working with the dev version and the 'default' is one way to do it. If we want historical data about Moose, I guess it's still possible to retrieve all latest packages at a given date. It will not be very different from what we used at this date. Now about the *release* process for Moose: sure I would like that there will be more releases. Now as Doru said, when we do a release, we should do it for every sub projects and it's bit difficult with the current tools. - One way to do automatically it is to use the test server to at least create a new version from the latest dev version and blessed it as 'tested' if 100% tests passed or 'broken' But I dont want such versions to pollute the manual versions, which are supposed to be stronger. So something like create automatically 'testedVersionXXX' with tests or broken as possible blessing. - Then we can do manual release from time to time (every two weeks, every months?), which requires more work as we have to do it for the different subprojects first, and blessed it as beta or stable. BTW, why is the beta version in Moose marked as 'baseline'? It does not make sense. It should be beta or stable. -- Simon