[Pharo-project] Best strategy for ConfigurationOfPharo using #stable
Hi Dale. For Pharo 1.3 I want to (try) to use all #stable, i.e, I want that ConfigurationOfPharo doesn't explicitly load a specific version of every project but instead, the #stable. First step I need to do (I will try to do it during the weekend) is to update #stable in each of the ConfigurationOf used by ConfuigurationOfPharo. That's an easy part. Now, my question is...I don't really understand how the confs would look like after. I mean, 99% of the cases (in fact, at the beginning it will be 100% until I find a problem), the version I use will be #stable. So,the version of ConfgiruationOfPharo AND all the Configurations used by ConfgiruationOfPharo would look something like this: spec project: 'Autotest' with: #stable; project: 'Autotest Help Tests' with: #stable; project: 'MemoryMonitor' with: #stable; project: 'XMLSupport' with: #stable; I mean...every single project reference will have #stable instead of a specific version. So...is this expected? is this the way I should do it ? Finally...is there a query I can do to Metacello saying "which are the ConfigurationsOf needed for this version for this group of this Conf" ? Thanks -- Mariano http://marianopeck.wordpress.com
On 04/29/2011 01:07 AM, Mariano Martinez Peck wrote:
Hi Dale. For Pharo 1.3 I want to (try) to use all #stable, i.e, I want that ConfigurationOfPharo doesn't explicitly load a specific version of every project but instead, the #stable. First step I need to do (I will try to do it during the weekend) is to update #stable in each of the ConfigurationOf used by ConfuigurationOfPharo. That's an easy part.
Now, my question is...I don't really understand how the confs would look like after. I mean, 99% of the cases (in fact, at the beginning it will be 100% until I find a problem), the version I use will be #stable. So,the version of ConfgiruationOfPharo AND all the Configurations used by ConfgiruationOfPharo would look something like this:
spec project: 'Autotest' with: #stable; project: 'Autotest Help Tests' with: #stable; project: 'MemoryMonitor' with: #stable; project: 'XMLSupport' with: #stable;
I mean...every single project reference will have #stable instead of a specific version. So...is this expected? is this the way I should do it ?
Finally...is there a query I can do to Metacello saying "which are the ConfigurationsOf needed for this version for this group of this Conf" ?
Thanks
-- Mariano http://marianopeck.wordpress.com
Mariano, My rule of thumb for a literal version spec is that you should use the #stable symbolic version if the project is loosely coupled to your project and a specific version otherwise. OmniBrowser tends to be loosely coupled as you are interested in getting any old version of OmniBrowser as long as it functions on the platform. The rule of thumb for a baseline version spec is to use #stable for all projects (as long as the #stable version is defined), even "tightly coupled" projects. When the baseline version is loaded, you normally don't want to load the "latest code" or all of the projects that you depend upon. The #bleedingEdge symbolic version should be used only when the referenced project is part of your project family. When I load the baseline version for Seaside30, I want to load the #bleedingEdge versions of Grease, Kom, and Swazoo, because they are part of the project family. I absolutely don't want to load the latest OmniBrowser code, because who knows what you'd get... So for the ConfigurationOfPharo, if you followed my rule of thumb, you would create a baseline version and use the #stable version for all of the projects in the baseline. In the literal version you would use the explicit version, so that you'd have an explicit repeatable specification for a set of projects that were known to work together. Developers interested in getting the "latest released version for all projects" in ConfigurationOfPharo would load the baseline version and then get the #stable version of all the projects for their platform ... each of the projects was know to work by itself in an image (that's what the #stable designation means), but the unknown is whether all of the projects work together in image ... When you know that, you create a literal version of ConfigurationOfPharo to commemorate that set of versions.... Without looking at the list of projects, it might still make sense to use #stable in the literal version, but it would be the exception to the rule ... Does this make sense to you? Dale
dale
My rule of thumb for a literal version spec is that you should use the #stable symbolic version if the project is loosely coupled to your project and a specific version otherwise. OmniBrowser tends to be loosely coupled as you are interested in getting any old version of OmniBrowser as long as it functions on the platform.
The rule of thumb for a baseline version spec is to use #stable for all projects (as long as the #stable version is defined), even "tightly coupled" projects. When the baseline version is loaded, you normally don't want to load the "latest code" or all of the projects that you depend upon.
The #bleedingEdge symbolic version should be used only when the referenced project is part of your project family.
When I load the baseline version for Seaside30,
when you say that "load the baseline": do you mean that you will get all the latest versions of the seaside packages?
I want to load the #bleedingEdge versions of Grease, Kom, and Swazoo, because they are part of the project family. I absolutely don't want to load the latest OmniBrowser code, because who knows what you'd get...
So for the ConfigurationOfPharo, if you followed my rule of thumb, you would create a baseline version and use the #stable version for all of the projects in the baseline. In the literal version you would use the explicit version, so that you'd have an explicit repeatable specification for a set of projects that were known to work together.
ok you mean that if people want the latest they load the baseline else they can just use a literal version and access it via #stable ?
Developers interested in getting the "latest released version for all projects" in ConfigurationOfPharo would load the baseline version and then get the #stable version of all the projects for their platform ... each of the projects was know to work by itself in an image (that's what the #stable designation means), but the unknown is whether all of the projects work together in image ... When you know that, you create a literal version of ConfigurationOfPharo to commemorate that set of versions....
Without looking at the list of projects, it might still make sense to use #stable in the literal version, but it would be the exception to the rule ...
Does this make sense to you?
Dale
On 04/29/2011 10:10 AM, Stéphane Ducasse wrote:
dale
My rule of thumb for a literal version spec is that you should use the #stable symbolic version if the project is loosely coupled to your project and a specific version otherwise. OmniBrowser tends to be loosely coupled as you are interested in getting any old version of OmniBrowser as long as it functions on the platform.
The rule of thumb for a baseline version spec is to use #stable for all projects (as long as the #stable version is defined), even "tightly coupled" projects. When the baseline version is loaded, you normally don't want to load the "latest code" or all of the projects that you depend upon.
The #bleedingEdge symbolic version should be used only when the referenced project is part of your project family.
When I load the baseline version for Seaside30,
when you say that "load the baseline": do you mean that you will get all the latest versions of the seaside packages?
Yes, I load the baseline version of Seaside30, to pick up the most recent checkins by the Seaside developers, so I can update the configuration, port the changes, to GemStone and make a release. And when I do that, I don't want the latest OmniBrowser packages:)
I want to load the #bleedingEdge versions of Grease, Kom, and Swazoo, because they are part of the project family. I absolutely don't want to load the latest OmniBrowser code, because who knows what you'd get...
So for the ConfigurationOfPharo, if you followed my rule of thumb, you would create a baseline version and use the #stable version for all of the projects in the baseline. In the literal version you would use the explicit version, so that you'd have an explicit repeatable specification for a set of projects that were known to work together.
ok you mean that if people want the latest they load the baseline else they can just use a literal version and access it via #stable
I'm not sure what you mean here.... The pharo 1.2.2-baseline would include specs that look like this: spec project: 'OB Dev' with: [ spec className: 'ConfigurationOfOmniBrowser'; versionString: #stable; ...]; project: 'ScriptManager' with: [ spec className: 'ConfigurationOfScriptManager'; versionString: #stable; ...]; project: 'Shout' with: [ spec className: 'ConfigurationOfShout'; versionString: #stable; ...]; ....]. Loading Pharo 1.2.2-baseline would cause the #stable version for each of those projects to be loaded ... but remember over time the #stable version will change and incompatibilities between packages can creep in. By using #stable versions you will be in better shape than using #bleedingEdge because the #stable version is known to work. Pharo 1.2.2 (literal version) will have corresponding specs that look like this: spec project: 'OB Dev' with: '1.2.4'; project: 'ScriptManager' with: '1.2'; project: 'Shout' with: '1.2.2'; ....]. So that you have driven a stake into the ground stating that these versions are known to work together (have passed tests as a unit). 5 years in the future, you will be able ot load Pharo 1.2.2 and get exactly the same packages every time ... whereas the #stable versions may have drifted over time ... If I am just bringing up a PharoCore1.2 image and I'd like to load the Pharo dev code, I should load the #stable version of Pharo (which may be 1.2.2 today and 1.2.3 tomorrow). If I want to duplicate the environment that someone is working in I will ask them for th version of Pharo and load that explicit version to reproduce the bug or whatever ... Dale
when you say that "load the baseline": do you mean that you will get all the latest versions of the seaside packages?
Yes, I load the baseline version of Seaside30, to pick up the most recent checkins by the Seaside developers, so I can update the configuration, port the changes, to GemStone and make a release.
And when I do that, I don't want the latest OmniBrowser packages:)
I want to load the #bleedingEdge versions of Grease, Kom, and Swazoo, because they are part of the project family. I absolutely don't want to load the latest OmniBrowser code, because who knows what you'd get...
So for the ConfigurationOfPharo, if you followed my rule of thumb, you would create a baseline version and use the #stable version for all of the projects in the baseline. In the literal version you would use the explicit version, so that you'd have an explicit repeatable specification for a set of projects that were known to work together.
ok you mean that if people want the latest they load the baseline else they can just use a literal version and access it via #stable
I'm not sure what you mean here....
The pharo 1.2.2-baseline would include specs that look like this:
spec project: 'OB Dev' with: [ spec className: 'ConfigurationOfOmniBrowser'; versionString: #stable; ...]; project: 'ScriptManager' with: [ spec className: 'ConfigurationOfScriptManager'; versionString: #stable; ...]; project: 'Shout' with: [ spec className: 'ConfigurationOfShout'; versionString: #stable; ...]; ....].
Loading Pharo 1.2.2-baseline would cause the #stable version for each of those projects to be loaded ... but remember over time the #stable version will change and incompatibilities between packages can creep in. By using #stable versions you will be in better shape than using #bleedingEdge because the #stable version is known to work.
Pharo 1.2.2 (literal version) will have corresponding specs that look like this:
spec project: 'OB Dev' with: '1.2.4'; project: 'ScriptManager' with: '1.2'; project: 'Shout' with: '1.2.2'; ....].
So that you have driven a stake into the ground stating that these versions are known to work together (have passed tests as a unit). 5 years in the future, you will be able ot load Pharo 1.2.2 and get exactly the same packages every time ... whereas the #stable versions may have drifted over time ...
Excellent point. I should add that to the book chapter!
If I am just bringing up a PharoCore1.2 image and I'd like to load the Pharo dev code, I should load the #stable version of Pharo (which may be 1.2.2 today and 1.2.3 tomorrow).
If I want to duplicate the environment that someone is working in I will ask them for th version of Pharo and load that explicit version to reproduce the bug or whatever ...
Dale
So.... I will add versionString: #stable To all confs directly used by ConfigurationOfPharo. But that's not enough. I should do the same to each of them...and the whole tree...shouldn't I ? Maybe if we set up this, hudson can load the latest baseline instead of #lastVersion as it is doing now... Cheers On Fri, Apr 29, 2011 at 8:34 PM, Dale Henrichs <dhenrich@vmware.com> wrote:
On 04/29/2011 10:10 AM, Stéphane Ducasse wrote:
dale
My rule of thumb for a literal version spec is that you should
use the #stable symbolic version if the project is loosely coupled to your project and a specific version otherwise. OmniBrowser tends to be loosely coupled as you are interested in getting any old version of OmniBrowser as long as it functions on the platform.
The rule of thumb for a baseline version spec is to use #stable for all projects (as long as the #stable version is defined), even "tightly coupled" projects. When the baseline version is loaded, you normally don't want to load the "latest code" or all of the projects that you depend upon.
The #bleedingEdge symbolic version should be used only when the referenced project is part of your project family.
When I load the baseline version for Seaside30,
when you say that "load the baseline": do you mean that you will get all the latest versions of the seaside packages?
Yes, I load the baseline version of Seaside30, to pick up the most recent checkins by the Seaside developers, so I can update the configuration, port the changes, to GemStone and make a release.
And when I do that, I don't want the latest OmniBrowser packages:)
I want to load the #bleedingEdge versions of Grease, Kom, and
Swazoo, because they are part of the project family. I absolutely don't want to load the latest OmniBrowser code, because who knows what you'd get...
So for the ConfigurationOfPharo, if you followed my rule of thumb, you would create a baseline version and use the #stable version for all of the projects in the baseline. In the literal version you would use the explicit version, so that you'd have an explicit repeatable specification for a set of projects that were known to work together.
ok you mean that if people want the latest they load the baseline else they can just use a literal version and access it via #stable
I'm not sure what you mean here....
The pharo 1.2.2-baseline would include specs that look like this:
spec project: 'OB Dev' with: [ spec className: 'ConfigurationOfOmniBrowser'; versionString: #stable; ...]; project: 'ScriptManager' with: [ spec className: 'ConfigurationOfScriptManager'; versionString: #stable; ...]; project: 'Shout' with: [ spec className: 'ConfigurationOfShout'; versionString: #stable; ...]; ....].
Loading Pharo 1.2.2-baseline would cause the #stable version for each of those projects to be loaded ... but remember over time the #stable version will change and incompatibilities between packages can creep in. By using #stable versions you will be in better shape than using #bleedingEdge because the #stable version is known to work.
Pharo 1.2.2 (literal version) will have corresponding specs that look like this:
spec project: 'OB Dev' with: '1.2.4'; project: 'ScriptManager' with: '1.2'; project: 'Shout' with: '1.2.2'; ....].
So that you have driven a stake into the ground stating that these versions are known to work together (have passed tests as a unit). 5 years in the future, you will be able ot load Pharo 1.2.2 and get exactly the same packages every time ... whereas the #stable versions may have drifted over time ...
If I am just bringing up a PharoCore1.2 image and I'd like to load the Pharo dev code, I should load the #stable version of Pharo (which may be 1.2.2 today and 1.2.3 tomorrow).
If I want to duplicate the environment that someone is working in I will ask them for th version of Pharo and load that explicit version to reproduce the bug or whatever ...
Dale
-- Mariano http://marianopeck.wordpress.com
Mariano,
My rule of thumb for a literal version spec is that you should use the #stable symbolic version if the project is loosely coupled to your project and a specific version otherwise. OmniBrowser tends to be loosely coupled as you are interested in getting any old version of OmniBrowser as long as it functions on the platform.
The rule of thumb for a baseline version spec is to use #stable for all projects (as long as the #stable version is defined), even "tightly coupled" projects. When the baseline version is loaded, you normally don't want to load the "latest code" or all of the projects that you depend upon.
The #bleedingEdge symbolic version should be used only when the referenced project is part of your project family.
When I load the baseline version for Seaside30, I want to load the #bleedingEdge versions of Grease, Kom, and Swazoo, because they are part of the project family. I absolutely don't want to load the latest OmniBrowser code, because who knows what you'd get...
So for the ConfigurationOfPharo, if you followed my rule of thumb, you would create a baseline version and use the #stable version for all of the projects in the baseline. In the literal version you would use the explicit version, so that you'd have an explicit repeatable specification for a set of projects that were known to work together.
Thanks Dale for the answer....Now, putting #stable in the versionString of a baseline make sense ONLY because the default is not #stable, isn't it ? I mean, if ConfigurationOfPharo >> baseline13: I am doing: project: 'OB Dev' with: [ spec className: 'ConfigurationOfOmniBrowser'; loads: #('Dev'); file: 'ConfigurationOfOmniBrowser'; repository: ' http://www.squeaksource.com/MetacelloRepository' ]; as you can see, in any baseline of ConfigurationOfPharo I set a version. Hence, if someone does ConfigurationOfPharo project version: '1.3-baseline', then Metacello will load the DEFAULT for 'ConfigurationOfOmniBrowser' which I guess it is not #stable becuase otherwise what you told me doesn't have sense. So, I guess it is #bleedingEdge? I think I have already asked this...sorry I couldn't find it in my gmail...
Developers interested in getting the "latest released version for all projects" in ConfigurationOfPharo would load the baseline version and then get the #stable version of all the projects for their platform ... each of the projects was know to work by itself in an image (that's what the #stable designation means), but the unknown is whether all of the projects work together in image ... When you know that, you create a literal version of ConfigurationOfPharo to commemorate that set of versions....
Without looking at the list of projects, it might still make sense to use #stable in the literal version, but it would be the exception to the rule ...
Does this make sense to you?
Totally :)
Dale
-- Mariano http://marianopeck.wordpress.com
participants (3)
-
Dale Henrichs -
Mariano Martinez Peck -
Stéphane Ducasse