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-fo...
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
just for information I'm collecting any information for a chapter on metacello.
Stef
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:
- 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.
- 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-fo...
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?
- 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
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Simon,
BTW, why is the beta version in Moose marked as 'baseline'? It does not make sense. It should be beta or stable.
Indeed, I forgot to mark the version40beta2 as #beta, so it inherited the #baseline blessing from baseline40beta2. It is fixed now.
Cheers, Doru
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
Ok make more sense.
Hi Simon,
BTW, why is the beta version in Moose marked as 'baseline'? It does not make sense. It should be beta or stable.
Indeed, I forgot to mark the version40beta2 as #beta, so it inherited the #baseline blessing from baseline40beta2. It is fixed now.
Cheers, Doru
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 3 déc. 2009, at 13:02, Simon Denier wrote:
*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.
What people can do if they work with the development version: they can always save the current versions of packages if they feel happy with it, in a 'devXXXSimWorkingOnIssue' method blessed as development. This will be like a branch and he can always start from here next time (this way, he is not offended by potential breaks in latest dev). But he should take care that it also merges well with the main trunk in the end, because that's from where we will make stable release.
-- Simon
On 3 déc. 2009, at 13:34, Simon Denier wrote:
On 3 déc. 2009, at 13:02, Simon Denier wrote:
*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.
What people can do if they work with the development version: they can always save the current versions of packages if they feel happy with it, in a 'devXXXSimWorkingOnIssue' method blessed as development. This will be like a branch and he can always start from here next time (this way, he is not offended by potential breaks in latest dev). But he should take care that it also merges well with the main trunk in the end, because that's from where we will make stable release.
Let's take an example with the latest CAnalyzer.
So I saved my changes in a new version which I called:
dev131: spec <version: '1.3.1' imports: #('1.3')>
spec for: #common do: [ spec author: 'simondenier'. spec timestamp: '12/3/2009 18:01'. spec blessing: #development. spec package: 'CAnalyzer' with: 'CAnalyzer-simondenier.166'; package: 'XML-Parser' with: 'XML-Parser-Alexandre_Bergel.19'; package: 'Pastell' with: 'Pastell-Alexandre_Bergel.17'; package: 'Filesystem' with: 'Filesystem-cwp.51'.].
As you can, it is blessed as development with a micro number (1.3.1)
So we can have three levels of release with Metacello: - baseline for the architecture - version for major and minor release, which can be stable, beta, or the main trunk of development - dev for micro release for developers, which we can see as branches, and which serves as history of development as Stef wishes
I called it dev, but maybe branch is a better name. Also a different blessing could be used, I dont know. Any idea?
Note that Metacello handles well the numbering of version at major, minor, or micro level.
Now about the process itself: - *update the configuration* so that you get other micro releases and you dont override one by accident :) - spawn new version from the minor or micro release you want to derive - save packages - you are prompted to update package methods, which means update your new version method with the package info - then you are prompted to save the configuration
It means that actually you need to do two commits: one for the packages, one for the configuration. Maybe we could improve the process and making the whole thing works seamlessly (save new version: spawn new version (prompt for version) -> save packages (prompt for comment) -> update version -> save configuration (reuse earlier comment).
-- Simon
So I saved my changes in a new version which I called:
dev131: spec <version: '1.3.1' imports: #('1.3')>
spec for: #common do: [ spec author: 'simondenier'. spec timestamp: '12/3/2009 18:01'. spec blessing: #development. spec package: 'CAnalyzer' with: 'CAnalyzer-simondenier.166'; package: 'XML-Parser' with: 'XML-Parser-Alexandre_Bergel.19'; package: 'Pastell' with: 'Pastell-Alexandre_Bergel.17'; package: 'Filesystem' with: 'Filesystem-cwp.51'.].
As you can, it is blessed as development with a micro number (1.3.1)
So we can have three levels of release with Metacello:
- baseline for the architecture
- version for major and minor release, which can be stable, beta, or the main trunk of development
- dev for micro release for developers, which we can see as branches, and which serves as history of development as Stef wishes
Sounds good to me.
I called it dev, but maybe branch is a better name. Also a different blessing could be used, I dont know. Any idea? Note that Metacello handles well the numbering of version at major, minor, or micro level.
Now about the process itself:
- *update the configuration* so that you get other micro releases and you dont override one by accident :)
- spawn new version from the minor or micro release you want to derive
- save packages
we have to do step that manually or this is a menu (publish all dirty package of that configuration)?
- you are prompted to update package methods, which means update your new version method with the package info
- then you are prompted to save the configuration
It means that actually you need to do two commits: one for the packages, one for the configuration. Maybe we could improve the process and making the whole thing works seamlessly (save new version: spawn new version (prompt for version) -> save packages (prompt for comment) -> update version -> save configuration (reuse earlier comment).
For now it can be what we need and if we should do two commits this is ok.
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 3 déc. 2009, at 19:00, Stéphane Ducasse wrote:
So I saved my changes in a new version which I called:
dev131: spec <version: '1.3.1' imports: #('1.3')>
spec for: #common do: [ spec author: 'simondenier'. spec timestamp: '12/3/2009 18:01'. spec blessing: #development. spec package: 'CAnalyzer' with: 'CAnalyzer-simondenier.166'; package: 'XML-Parser' with: 'XML-Parser-Alexandre_Bergel.19'; package: 'Pastell' with: 'Pastell-Alexandre_Bergel.17'; package: 'Filesystem' with: 'Filesystem-cwp.51'.].
As you can, it is blessed as development with a micro number (1.3.1)
So we can have three levels of release with Metacello:
- baseline for the architecture
- version for major and minor release, which can be stable, beta,
or the main trunk of development
- dev for micro release for developers, which we can see as
branches, and which serves as history of development as Stef wishes
Sounds good to me.
I called it dev, but maybe branch is a better name. Also a different blessing could be used, I dont know. Any idea? Note that Metacello handles well the numbering of version at major, minor, or micro level.
Now about the process itself:
- *update the configuration* so that you get other micro releases
and you dont override one by accident :)
- spawn new version from the minor or micro release you want to
derive
- save packages
we have to do step that manually or this is a menu (publish all dirty package of that configuration)?
This is in the menu.
Now there is issue #3 which dates back from september and in which apparently, new packages are not saved this way, only dirty.
Also I dont know if this works with nested configurations (but perhaps it's less important, we can make two separate commits in this case, one for each project).
- you are prompted to update package methods, which means update
your new version method with the package info
- then you are prompted to save the configuration
It means that actually you need to do two commits: one for the packages, one for the configuration. Maybe we could improve the process and making the whole thing works seamlessly (save new version: spawn new version (prompt for version) -> save packages (prompt for comment) -> update version -> save configuration (reuse earlier comment).
For now it can be what we need and if we should do two commits this is ok.
The first 3 steps you have to click in the contextual menu of the Configuration, then the last two follows the 'save packages'. But all are options in the menu http://code.google.com/p/metacello/wiki/MetacelloTools (5 out of 8 actions, good shooting)
-- Simon
Hi,
On 3 Dec 2009, at 23:12, Simon Denier wrote:
On 3 déc. 2009, at 19:00, Stéphane Ducasse wrote:
So I saved my changes in a new version which I called:
dev131: spec <version: '1.3.1' imports: #('1.3')>
spec for: #common do: [ spec author: 'simondenier'. spec timestamp: '12/3/2009 18:01'. spec blessing: #development. spec package: 'CAnalyzer' with: 'CAnalyzer-simondenier.166'; package: 'XML-Parser' with: 'XML-Parser-Alexandre_Bergel.19'; package: 'Pastell' with: 'Pastell-Alexandre_Bergel.17'; package: 'Filesystem' with: 'Filesystem-cwp.51'.].
As you can, it is blessed as development with a micro number (1.3.1)
So we can have three levels of release with Metacello:
- baseline for the architecture
- version for major and minor release, which can be stable, beta,
or the main trunk of development
- dev for micro release for developers, which we can see as
branches, and which serves as history of development as Stef wishes
Sounds good to me.
I called it dev, but maybe branch is a better name. Also a different blessing could be used, I dont know. Any idea? Note that Metacello handles well the numbering of version at major, minor, or micro level.
Now about the process itself:
- *update the configuration* so that you get other micro releases
and you dont override one by accident :)
- spawn new version from the minor or micro release you want to
derive
- save packages
we have to do step that manually or this is a menu (publish all dirty package of that configuration)?
This is in the menu.
Now there is issue #3 which dates back from september and in which apparently, new packages are not saved this way, only dirty.
Also I dont know if this works with nested configurations (but perhaps it's less important, we can make two separate commits in this case, one for each project).
The problem is that if we rely on 2 commits we also have to manually enter the version of the subproject in the overall project. This is very error prone. This is because there is no clear way to know what is the current version of the sub-project.
I see two possibilities here: 1. Just take the lastStableVersion from each subproject. This would rely on the assumption that someone has created already a version. 2. Detect the current version of a subproject by comparing the version written in the configuration with the monticello working copy version.
Doru
- you are prompted to update package methods, which means update
your new version method with the package info
- then you are prompted to save the configuration
It means that actually you need to do two commits: one for the packages, one for the configuration. Maybe we could improve the process and making the whole thing works seamlessly (save new version: spawn new version (prompt for version) -> save packages (prompt for comment) -> update version -> save configuration (reuse earlier comment).
For now it can be what we need and if we should do two commits this is ok.
The first 3 steps you have to click in the contextual menu of the Configuration, then the last two follows the 'save packages'. But all are options in the menu http://code.google.com/p/metacello/wiki/MetacelloTools (5 out of 8 actions, good shooting)
-- Simon
-- www.tudorgirba.com
"Some battles are better lost than fought."
*About the Moose process* I dont think the Pharo process and the Moose process compare.
I think that you are wrong. they both need a map. A specification of what to load
I do not see why saving XXX and not be able to reload XXX package is cool to your eyes. It makes no sense! with the current process: you publish X Y Z and I put Y1 after and you cannot reload your X Y Z so you are fucked up.
Now you say map1 = X Y Z and I say map2 = X Y1 Z and we can all reload what you want.
You do not have to oppose map or absence behind a process. You can publish map without having to run test.
With your approach we have no way to spot a vicious bug that requires to go back in time. In pharo sometimes we are forced to do that.
This is a technical problem and it has nothing to do with process. We should have maps.
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.
I disagree. Totally.
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.
This is a crappy and bad way of doing that. This is a SVN regression. Let us study the commit fingerprint to know what where the files that worked together: but we know it and we have a tools to save it.
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'
it will not work because we do not have good test coverage. Now we know that a version is composed of a set of specific compoentns so just save it.
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.
We are talking about the wrong tool to fix the problem.
- 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.
come on it worked in moose in store, it worked with Moose-all (modulo the subprojects even if I prefered Moose-all than the current situation).
You do a change you commit. You create a map with all the components that worked together at that point. Period. After you can tag a map as release, broken whatever but you know that you have a map of components!
Stef
On 3 déc. 2009, at 13:56, Stéphane Ducasse wrote:
*About the Moose process* I dont think the Pharo process and the Moose process compare.
I think that you are wrong. they both need a map. A specification of what to load
I do not see why saving XXX and not be able to reload XXX package is cool to your eyes. It makes no sense! with the current process: you publish X Y Z and I put Y1 after and you cannot reload your X Y Z so you are fucked up.
Let's be stupid: I can reload X Y Z, it's just not so easy sometimes.
Now you say map1 = X Y Z and I say map2 = X Y1 Z and we can all reload what you want.
You do not have to oppose map or absence behind a process. You can publish map without having to run test.
With your approach we have no way to spot a vicious bug that requires to go back in time. In pharo sometimes we are forced to do that.
This is a technical problem and it has nothing to do with process. We should have maps.
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.
I disagree. Totally.
You did not convince me :)
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.
This is a crappy and bad way of doing that. This is a SVN regression. Let us study the commit fingerprint to know what where the files that worked together: but we know it and we have a tools to save it.
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'
it will not work because we do not have good test coverage. Now we know that a version is composed of a set of specific compoentns so just save it.
At one point in time, we just know that the branch in which we are working may be ok (partially, because we dont test everything). Meanwhile, there are plenty of other changes. I just want to be clear that with this development process, we can not take any development version as a precise picture of the status of Moose at the time of development, because in general it is a branch.
So I proposed something in a later mail about creating 'dev' version. Then one sould be careful it's a dev, not a stable version, so I want a different name and different numbering schema like 1.3.x Problem is I dont think Metacello can handle automatic numbering.
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.
We are talking about the wrong tool to fix the problem.
- 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.
come on it worked in moose in store, it worked with Moose-all (modulo the subprojects even if I prefered Moose-all than the current situation).
Did not scale with Moose-All. Everytime someone committed Moose-All before you did, you had to be careful with merging.
-- Simon
On Dec 3, 2009, at 6:51 PM, Simon Denier wrote:
On 3 déc. 2009, at 13:56, Stéphane Ducasse wrote:
*About the Moose process* I dont think the Pharo process and the Moose process compare.
I think that you are wrong. they both need a map. A specification of what to load
I do not see why saving XXX and not be able to reload XXX package is cool to your eyes. It makes no sense! with the current process: you publish X Y Z and I put Y1 after and you cannot reload your X Y Z so you are fucked up.
Let's be stupid: I can reload X Y Z, it's just not so easy sometimes.
come on simon. if we want to generate data automatically we cannot tinkle for example for a new paper lukas rebuild all the pier versions since the beginning and rerun all the tests and run the smalllint rules. adrian could do the same
Now you say map1 = X Y Z and I say map2 = X Y1 Z and we can all reload what you want.
You do not have to oppose map or absence behind a process. You can publish map without having to run test.
With your approach we have no way to spot a vicious bug that requires to go back in time. In pharo sometimes we are forced to do that.
This is a technical problem and it has nothing to do with process. We should have maps.
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.
I disagree. Totally.
You did not convince me :)
my point is without we cannot do anything at ***all***. with a map we could reason on it and perform semi automatic merging, testing.... Now we just load the latest version and pray.
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.
This is a crappy and bad way of doing that. This is a SVN regression. Let us study the commit fingerprint to know what where the files that worked together: but we know it and we have a tools to save it.
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'
it will not work because we do not have good test coverage. Now we know that a version is composed of a set of specific compoentns so just save it.
At one point in time, we just know that the branch in which we are working may be ok (partially, because we dont test everything). Meanwhile, there are plenty of other changes. I just want to be clear that with this development process, we can not take any development version as a precise picture of the status of Moose at the time of development, because in general it is a branch.
sure then you flag it.
So I proposed something in a later mail about creating 'dev' version. Then one sould be careful it's a dev, not a stable version, so I want a different name and different numbering schema like 1.3.x
probably.
Problem is I dont think Metacello can handle automatic numbering.
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.
We are talking about the wrong tool to fix the problem.
- 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.
come on it worked in moose in store, it worked with Moose-all (modulo the subprojects even if I prefered Moose-all than the current situation).
Did not scale with Moose-All. Everytime someone committed Moose-All before you did, you had to be careful with merging.
Yes now we are not careful with merging at all. It works by accident. Now with a systematic map we have the same but in addition we can reproduce it and build tools on top of it.
I can give a try and during the next two weeks damage Moose randomly you will see you will have a terrible time to chase them besides throwing away all the packages I commit. So this is clearly a clear lack of maps.
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Simon,
On 3 Dec 2009, at 17:02, Simon Denier wrote:
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)
updateDefault should update the nested configurations now.
Cheers, Doru
-- www.tudorgirba.com
"Don't give to get. Just give."
-
Simon Denier -
Stéphane Ducasse -
Tudor Girba