So.... I will add versionString: #stable<br>To all confs directly used by ConfigurationOfPharo. <br>But that&#39;s not enough. I should do the same to each of them...and the whole tree...shouldn&#39;t I ?<br><br>Maybe if we set up this, hudson can load the latest baseline instead of #lastVersion as it is doing now...<br>
<br>Cheers<br><br><br><div class="gmail_quote">On Fri, Apr 29, 2011 at 8:34 PM, Dale Henrichs <span dir="ltr">&lt;<a href="mailto:dhenrich@vmware.com">dhenrich@vmware.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 04/29/2011 10:10 AM, Stéphane Ducasse wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
dale<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My rule of thumb for a literal version spec is that you should<br>
use the #stable symbolic version if the project is loosely<br>
coupled to your project and a specific version otherwise.<br>
OmniBrowser tends to be loosely coupled as you are interested in<br>
getting any old version of OmniBrowser as long as it functions on<br>
the platform.<br>
</blockquote>
<br>
The rule of thumb for a baseline version spec is to use #stable for<br>
all projects (as long as the #stable version is defined), even<br>
&quot;tightly coupled&quot; projects. When the baseline version is loaded,<br>
you normally don&#39;t want to load the &quot;latest code&quot; or all of the<br>
projects that you depend upon.<br>
<br>
The #bleedingEdge symbolic version should be used only when the<br>
referenced project is part of your project family.<br>
<br>
When I load the baseline version for Seaside30,<br>
</blockquote>
<br>
when you say that &quot;load the baseline&quot;: do you mean that you will get<br>
all the latest versions of the seaside packages?<br>
</blockquote>
<br></div>
Yes, I load the baseline version of Seaside30, to pick up the most<br>
recent checkins by the Seaside developers, so I can update the<br>
configuration, port the changes, to GemStone and make a release.<br>
<br>
And when I do that, I don&#39;t want the latest OmniBrowser packages:)<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I want to load the #bleedingEdge versions of Grease, Kom, and<br>
Swazoo, because they are part of the project family. I absolutely<br>
don&#39;t want to load the latest OmniBrowser code, because who knows<br>
what you&#39;d get...<br>
<br>
So for the ConfigurationOfPharo, if you followed my rule of thumb,<br>
you would create a baseline version and use the #stable version for<br>
all of the projects in the baseline. In the literal version you<br>
would use the explicit version, so that you&#39;d have an explicit<br>
repeatable specification for a set of projects that were known to<br>
work together.<br>
</blockquote>
<br>
ok you mean that if people want the latest they load the baseline<br>
else they can just use a literal version and access it via #stable<br>
</blockquote>
<br>
<br></div>
I&#39;m not sure what you mean here....<br>
<br>
The pharo 1.2.2-baseline would include specs that look like this:<br>
<br>
  spec<br>
    project: &#39;OB Dev&#39; with: [<br>
      spec<br>
        className: &#39;ConfigurationOfOmniBrowser&#39;;<br>
        versionString: #stable;<br>
        ...];<br>
    project: &#39;ScriptManager&#39; with: [<br>
      spec<br>
        className: &#39;ConfigurationOfScriptManager&#39;;<br>
        versionString: #stable;<br>
        ...];<br>
    project: &#39;Shout&#39; with: [<br>
      spec<br>
        className: &#39;ConfigurationOfShout&#39;;<br>
        versionString: #stable;<br>
        ...];<br>
    ....].<br>
<br>
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.<br>

<br>
Pharo 1.2.2 (literal version) will have corresponding specs that look like this:<br>
<br>
  spec<br>
    project: &#39;OB Dev&#39; with: &#39;1.2.4&#39;;<br>
    project: &#39;ScriptManager&#39; with: &#39;1.2&#39;;<br>
    project: &#39;Shout&#39; with: &#39;1.2.2&#39;;<br>
    ....].<br>
<br>
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 ...<br>

<br>
If I am just bringing up a PharoCore1.2 image and I&#39;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).<br>
<br>
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 ...<br><font color="#888888">
<br>
Dale<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br><br>