symbolic version proof of concept...

> Over the last few days I've been working on converting
> ConfigurationOfOmniBrowser and the configurations it depends upon
> (ConfigurationOfRefactoringBrowser, ConfigurationOfShout, and
> ConfigurationOfOCompletion) to use symbolic versions.
>
> The results are stashed away in a repository on the Bibliocello site:
>
>  http://a-bibliocello.gemstone.com/bibliocello/projects/Pharo/repository/Experiment1/MetacelloRepository
>
> With Metacello 1.0-beta.28 loaded you can execute the following
> expression in a PharoCore1.0, PharoCore1.1, or PharoCore1.2 image and
> the appropriate versions of OmniBrowser and the supporting proejcts
> will be loaded:
>
>  (ConfigurationOfOmniBrowser project version: #stable) load: 'Tests'.
>
> So far I have  been using only the 'Tests' group because ... well I
> want to verify that the code not only loads, but passes all of the
> tests (for the loaded projects) in each image and the results are:
>
>  PharoCore1.0:
>    1221 run, 1218 passes, 3 expected failures,
>      0 failures, 0 errors, 0 unexpected passes
>  PharoCore1.1:
>    1325 run, 1324 passes, 1 expected failures,
>      0 failures, 0 errors, 0 unexpected passes
>  PharoCore1.2:
>    814 run, 813 expected passes,
>      0 expected failures, 0 failures, 1 errors, 0 unexpected passes,
>      and deprecation warnings
>
> For Pharo1.2, OB-Refactory is not loaded, because it doesn't appear to
> have been ported to Pharo1.2 yet ...
>
> If you want to look at what I've done you can compare the latest
> version of the config with the earliest version of the config in the
> repository ... I'll be glad to explain any changes that don't make
> sense to you.
>
> All four configs also run clean against the Metacello validator ....
>
> I've developed a set of scripts (in MetacelloToolBox) that I have been
> using to automate the process of determining which versions in a
> particular configuration load cleanly into an image and if the tests
> pass as well (including checking for deprecation warnings). The
> following expression when executed in a PharoCore1.0.x image will load
> each version in the configuration and run the tests (loading the
> 'Tests' group if it is defined):
>
>  (MetacelloToolBox
> validatePlatformLoad: #'pharo1.0.x' for: 'OmniBrowser') explore.
>
> Right now, that script will automatically update the development and
> stable symbolic version definitions as well as mark versions as
> #release if the 'Tests' group loads without errors or deprecation
> warnings and passes all of the tests (without deprecation warnings).
> It also produces an 'issues list' that describes the individual
> errors, critical warnings and warnings for each version ... much like
> the validator with added information about tests.
>
> I expect to continue working my way through the various configurations
> with the goal to automate as much of the validation and analysis as
> possible...
>
> Dale

> Is there a short description of symbolic versions somewhere?
>
> Alexandre
>
>
> On 24 Nov 2010, at 21:46, Dale wrote:
>
>> Over the last few days I've been working on converting
>> ConfigurationOfOmniBrowser and the configurations it depends upon
>> (ConfigurationOfRefactoringBrowser, ConfigurationOfShout, and
>> ConfigurationOfOCompletion) to use symbolic versions.
>>
>> The results are stashed away in a repository on the Bibliocello site:
>>
>> http://a-bibliocello.gemstone.com/bibliocello/projects/Pharo/repository/Experiment1/MetacelloRepository
>>
>> With Metacello 1.0-beta.28 loaded you can execute the following
>> expression in a PharoCore1.0, PharoCore1.1, or PharoCore1.2 image and
>> the appropriate versions of OmniBrowser and the supporting proejcts
>> will be loaded:
>>
>> (ConfigurationOfOmniBrowser project version: #stable) load: 'Tests'.
>>
>> So far I have  been using only the 'Tests' group because ... well I
>> want to verify that the code not only loads, but passes all of the
>> tests (for the loaded projects) in each image and the results are:
>>
>> PharoCore1.0:
>>   1221 run, 1218 passes, 3 expected failures,
>>     0 failures, 0 errors, 0 unexpected passes
>> PharoCore1.1:
>>   1325 run, 1324 passes, 1 expected failures,
>>     0 failures, 0 errors, 0 unexpected passes
>> PharoCore1.2:
>>   814 run, 813 expected passes,
>>     0 expected failures, 0 failures, 1 errors, 0 unexpected passes,
>>     and deprecation warnings
>>
>> For Pharo1.2, OB-Refactory is not loaded, because it doesn't appear to
>> have been ported to Pharo1.2 yet ...
>>
>> If you want to look at what I've done you can compare the latest
>> version of the config with the earliest version of the config in the
>> repository ... I'll be glad to explain any changes that don't make
>> sense to you.
>>
>> All four configs also run clean against the Metacello validator ....
>>
>> I've developed a set of scripts (in MetacelloToolBox) that I have been
>> using to automate the process of determining which versions in a
>> particular configuration load cleanly into an image and if the tests
>> pass as well (including checking for deprecation warnings). The
>> following expression when executed in a PharoCore1.0.x image will load
>> each version in the configuration and run the tests (loading the
>> 'Tests' group if it is defined):
>>
>> (MetacelloToolBox
>> validatePlatformLoad: #'pharo1.0.x' for: 'OmniBrowser') explore.
>>
>> Right now, that script will automatically update the development and
>> stable symbolic version definitions as well as mark versions as
>> #release if the 'Tests' group loads without errors or deprecation
>> warnings and passes all of the tests (without deprecation warnings).
>> It also produces an 'issues list' that describes the individual
>> errors, critical warnings and warnings for each version ... much like
>> the validator with added information about tests.
>>
>> I expect to continue working my way through the various configurations
>> with the goal to automate as much of the validation and analysis as
>> possible...
>>
>> Dale
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

> Hi,
>
> I tried:
> Gofer new
>         url: 'http://a-bibliocello.gemstone.com/bibliocello/projects/Pharo/reposito...
>         package: 'ConfigurationOfOmniBrowser';
>         load.
>  ((Smalltalk at: #ConfigurationOfOmniBrowser) project version: #stable) load: 'Tests'.
>
> But the (ConfigurationOfOmniBrowser project version: #stable) is nil.
>
> Cheers,
> Doru
>
> On 25 Nov 2010, at 12:21, Alexandre Bergel wrote:
>
>
>
> > Is there a short description of symbolic versions somewhere?
>
> > Alexandre
>
> > On 24 Nov 2010, at 21:46, Dale wrote:
>
> >> Over the last few days I've been working on converting
> >> ConfigurationOfOmniBrowser and the configurations it depends upon
> >> (ConfigurationOfRefactoringBrowser, ConfigurationOfShout, and
> >> ConfigurationOfOCompletion) to use symbolic versions.
>
> >> The results are stashed away in a repository on the Bibliocello site:
>
> >>http://a-bibliocello.gemstone.com/bibliocello/projects/Pharo/reposito...
>
> >> With Metacello 1.0-beta.28 loaded you can execute the following
> >> expression in a PharoCore1.0, PharoCore1.1, or PharoCore1.2 image and
> >> the appropriate versions of OmniBrowser and the supporting proejcts
> >> will be loaded:
>
> >> (ConfigurationOfOmniBrowser project version: #stable) load: 'Tests'.
>
> >> So far I have  been using only the 'Tests' group because ... well I
> >> want to verify that the code not only loads, but passes all of the
> >> tests (for the loaded projects) in each image and the results are:
>
> >> PharoCore1.0:
> >>   1221 run, 1218 passes, 3 expected failures,
> >>     0 failures, 0 errors, 0 unexpected passes
> >> PharoCore1.1:
> >>   1325 run, 1324 passes, 1 expected failures,
> >>     0 failures, 0 errors, 0 unexpected passes
> >> PharoCore1.2:
> >>   814 run, 813 expected passes,
> >>     0 expected failures, 0 failures, 1 errors, 0 unexpected passes,
> >>     and deprecation warnings
>
> >> For Pharo1.2, OB-Refactory is not loaded, because it doesn't appear to
> >> have been ported to Pharo1.2 yet ...
>
> >> If you want to look at what I've done you can compare the latest
> >> version of the config with the earliest version of the config in the
> >> repository ... I'll be glad to explain any changes that don't make
> >> sense to you.
>
> >> All four configs also run clean against the Metacello validator ....
>
> >> I've developed a set of scripts (in MetacelloToolBox) that I have been
> >> using to automate the process of determining which versions in a
> >> particular configuration load cleanly into an image and if the tests
> >> pass as well (including checking for deprecation warnings). The
> >> following expression when executed in a PharoCore1.0.x image will load
> >> each version in the configuration and run the tests (loading the
> >> 'Tests' group if it is defined):
>
> >> (MetacelloToolBox
> >>        validatePlatformLoad: #'pharo1.0.x' for: 'OmniBrowser') explore.
>
> >> Right now, that script will automatically update the development and
> >> stable symbolic version definitions as well as mark versions as
> >> #release if the 'Tests' group loads without errors or deprecation
> >> warnings and passes all of the tests (without deprecation warnings).
> >> It also produces an 'issues list' that describes the individual
> >> errors, critical warnings and warnings for each version ... much like
> >> the validator with added information about tests.
>
> >> I expect to continue working my way through the various configurations
> >> with the goal to automate as much of the validation and analysis as
> >> possible...
>
> >> Dale
>
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
> --www.tudorgirba.com
>
> "In a world where everything is moving ever faster,
> one might have better chances to win by moving slower."

> Is there a short description of symbolic versions somewhere?
>
> Alexandre
>
> On 24 Nov 2010, at 21:46, Dale wrote:
>
>
>
> > Over the last few days I've been working on converting
> > ConfigurationOfOmniBrowser and the configurations it depends upon
> > (ConfigurationOfRefactoringBrowser, ConfigurationOfShout, and
> > ConfigurationOfOCompletion) to use symbolic versions.
>
> > The results are stashed away in a repository on the Bibliocello site:
>
> >  http://a-bibliocello.gemstone.com/bibliocello/projects/Pharo/reposito...
>
> > With Metacello 1.0-beta.28 loaded you can execute the following
> > expression in a PharoCore1.0, PharoCore1.1, or PharoCore1.2 image and
> > the appropriate versions of OmniBrowser and the supporting proejcts
> > will be loaded:
>
> >  (ConfigurationOfOmniBrowser project version: #stable) load: 'Tests'.
>
> > So far I have  been using only the 'Tests' group because ... well I
> > want to verify that the code not only loads, but passes all of the
> > tests (for the loaded projects) in each image and the results are:
>
> >  PharoCore1.0:
> >    1221 run, 1218 passes, 3 expected failures,
> >      0 failures, 0 errors, 0 unexpected passes
> >  PharoCore1.1:
> >    1325 run, 1324 passes, 1 expected failures,
> >      0 failures, 0 errors, 0 unexpected passes
> >  PharoCore1.2:
> >    814 run, 813 expected passes,
> >      0 expected failures, 0 failures, 1 errors, 0 unexpected passes,
> >      and deprecation warnings
>
> > For Pharo1.2, OB-Refactory is not loaded, because it doesn't appear to
> > have been ported to Pharo1.2 yet ...
>
> > If you want to look at what I've done you can compare the latest
> > version of the config with the earliest version of the config in the
> > repository ... I'll be glad to explain any changes that don't make
> > sense to you.
>
> > All four configs also run clean against the Metacello validator ....
>
> > I've developed a set of scripts (in MetacelloToolBox) that I have been
> > using to automate the process of determining which versions in a
> > particular configuration load cleanly into an image and if the tests
> > pass as well (including checking for deprecation warnings). The
> > following expression when executed in a PharoCore1.0.x image will load
> > each version in the configuration and run the tests (loading the
> > 'Tests' group if it is defined):
>
> >  (MetacelloToolBox
> >    validatePlatformLoad: #'pharo1.0.x' for: 'OmniBrowser') explore.
>
> > Right now, that script will automatically update the development and
> > stable symbolic version definitions as well as mark versions as
> > #release if the 'Tests' group loads without errors or deprecation
> > warnings and passes all of the tests (without deprecation warnings).
> > It also produces an 'issues list' that describes the individual
> > errors, critical warnings and warnings for each version ... much like
> > the validator with added information about tests.
>
> > I expect to continue working my way through the various configurations
> > with the goal to automate as much of the validation and analysis as
> > possible...
>
> > Dale
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

> Alexandre,
>
> Not yet ... I'm still expecting to tweak a thing or two with symbolic
> versions, but I can take a crack at a short description of what I've
> got so far.
>
> From the beginning Metacello has had the notion of loading the latest
> version. The expectation was that loading the latest release would
> always be the best thing to do.
>
> As Pharo has moved forward, aggressively cleaning up the base image,
> it has turned out that loading the latest version isn't always the
> best solution:
>
>  - code that runs in Pharo1.0 won't work in Pharo1.2 and vice versa
>
> To solve this problem we need to be able to describe the 'latest
> version' on a platform by platform basis.
>
> 'latest version' is only one of the dimensions that we're interested
> in. At this point in time, there are really three version dimensions
> that are interesting:
>
>  bleedingEdge - the latest mcz file defined in the latest baseline
> for a
>                        project.
>  development - the currently active development version
>  stable           - what we really want when we say 'latest version'
>
> I expect that over time there will be additional dimensions over time.
> For Metacello I've already played with #earlyAccess versions which are
> 'stable' development versions.
>
> The requirement is to be able to declare a #stable or #development
> version on a platform by platform basis. So we've added an two
> additional pragmas that can be included in Configuration class
> methods:
>
>  <symbolicVersion: SYMBOLIC_VERSION_SYMBOL>
>  <defaultSymbolicVersion: SYMBOLIC_VERSION_SYMBOL>
>
> The #symbolicVersion: pragma is similar to the version pragma
> (<version: VERSION_STRING>). The following is an example where a set
> of #stable symbolic versions are declared:
>
>  stable: spec
> <symbolicVersion: #'stable'>
>
> spec for: #'common' version: '1.0.2.1'.
> spec for: #'pharo1.0.x' version: '1.0.2.1'.
> spec for: #'pharo1.1.x' version: '1.0.3'.
> spec for: #'pharo1.2.x' version: '1.0.4'.
>
> The #defaultSymbolicVersion: is used in a method that is expected to
> be regular smalltalk code that returns a version string. The following
> is the definition for the #bleedingEdge symbolic version:
>
>  bleedingEdge
> <defaultSymbolicVersion: #bleedingEdge>
>
> | bleedingEdgeVersion |
> bleedingEdgeVersion := (self project map values select: [ :version |
> version blessing == #baseline ])
> detectMax: [ :version | version ].
> bleedingEdgeVersion ifNil: [ bleedingEdgeVersion := self project
> latestVersion ].
> bleedingEdgeVersion
> ifNil: [ self versionDoesNotExistError: #bleedingEdge ].
> ^ bleedingEdgeVersion versionString
>
> When specifying a symbolic version with a #symbolicVersion: pragma it
> is legal to use another symbolic version like the following definition
> for the symbolic version #stable:
>
>  stable: spec
> <symbolicVersion: #'stable'>
>
> spec for: #'gemstone' version: '1.5'.
> spec for: #'squeak' version: '1.4'.
> spec for: #'pharo1.0.x' version: '1.5'.
> spec for: #'pharo1.1.x' version: '1.5'.
> spec for: #'pharo1.2.x' version: #development.
>
> Or to use the special symbolic version #notDefined: as in the
> following definition of the symbolic version #development:
>
>  development: spec
> <symbolicVersion: #'development'>
>
> spec for: #'common' version: #notDefined.
> spec for: #'pharo1.1.x' version: '1.6'.
> spec for: #'pharo1.2.x' version: '1.6'.
>
> Using a symbolic version that resolves to #notDefined will result in a
> MetacelloSymbolicVersionNotDefinedError being signalled.
>
> A symbolic version may be used anywhere that a literal version may be
> used.
>
> Well, this should cover the basics...
>
> Dale
>
> On Nov 25, 3:21 am, Alexandre Bergel <[hidden email]> wrote:
>> Is there a short description of symbolic versions somewhere?
>>
>> Alexandre
>>
>> On 24 Nov 2010, at 21:46, Dale wrote:
>>
>>
>>
>>> Over the last few days I've been working on converting
>>> ConfigurationOfOmniBrowser and the configurations it depends upon
>>> (ConfigurationOfRefactoringBrowser, ConfigurationOfShout, and
>>> ConfigurationOfOCompletion) to use symbolic versions.
>>
>>> The results are stashed away in a repository on the Bibliocello site:
>>
>>>  http://a-bibliocello.gemstone.com/bibliocello/projects/Pharo/reposito...
>>
>>> With Metacello 1.0-beta.28 loaded you can execute the following
>>> expression in a PharoCore1.0, PharoCore1.1, or PharoCore1.2 image and
>>> the appropriate versions of OmniBrowser and the supporting proejcts
>>> will be loaded:
>>
>>>  (ConfigurationOfOmniBrowser project version: #stable) load: 'Tests'.
>>
>>> So far I have  been using only the 'Tests' group because ... well I
>>> want to verify that the code not only loads, but passes all of the
>>> tests (for the loaded projects) in each image and the results are:
>>
>>>  PharoCore1.0:
>>>    1221 run, 1218 passes, 3 expected failures,
>>>      0 failures, 0 errors, 0 unexpected passes
>>>  PharoCore1.1:
>>>    1325 run, 1324 passes, 1 expected failures,
>>>      0 failures, 0 errors, 0 unexpected passes
>>>  PharoCore1.2:
>>>    814 run, 813 expected passes,
>>>      0 expected failures, 0 failures, 1 errors, 0 unexpected passes,
>>>      and deprecation warnings
>>
>>> For Pharo1.2, OB-Refactory is not loaded, because it doesn't appear to
>>> have been ported to Pharo1.2 yet ...
>>
>>> If you want to look at what I've done you can compare the latest
>>> version of the config with the earliest version of the config in the
>>> repository ... I'll be glad to explain any changes that don't make
>>> sense to you.
>>
>>> All four configs also run clean against the Metacello validator ....
>>
>>> I've developed a set of scripts (in MetacelloToolBox) that I have been
>>> using to automate the process of determining which versions in a
>>> particular configuration load cleanly into an image and if the tests
>>> pass as well (including checking for deprecation warnings). The
>>> following expression when executed in a PharoCore1.0.x image will load
>>> each version in the configuration and run the tests (loading the
>>> 'Tests' group if it is defined):
>>
>>>  (MetacelloToolBox
>>>    validatePlatformLoad: #'pharo1.0.x' for: 'OmniBrowser') explore.
>>
>>> Right now, that script will automatically update the development and
>>> stable symbolic version definitions as well as mark versions as
>>> #release if the 'Tests' group loads without errors or deprecation
>>> warnings and passes all of the tests (without deprecation warnings).
>>> It also produces an 'issues list' that describes the individual
>>> errors, critical warnings and warnings for each version ... much like
>>> the validator with added information about tests.
>>
>>> I expect to continue working my way through the various configurations
>>> with the goal to automate as much of the validation and analysis as
>>> possible...
>>
>>> Dale
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

> Ok. But why not simply having
> ConfigurationOfMondrian class>>  loadForPharo12
>    (self project version: 'default') load
>
> ConfigurationOfMondrian loadForPharo111
>    (self project version: '2.1.2') load
>
> ?
>
> Alexandre
>
> On 25 Nov 2010, at 13:44, Dale wrote:
>
>> Alexandre,
>>
>> Not yet ... I'm still expecting to tweak a thing or two with symbolic
>> versions, but I can take a crack at a short description of what I've
>> got so far.
>>
>>  From the beginning Metacello has had the notion of loading the latest
>> version. The expectation was that loading the latest release would
>> always be the best thing to do.
>>
>> As Pharo has moved forward, aggressively cleaning up the base image,
>> it has turned out that loading the latest version isn't always the
>> best solution:
>>
>>   - code that runs in Pharo1.0 won't work in Pharo1.2 and vice versa
>>
>> To solve this problem we need to be able to describe the 'latest
>> version' on a platform by platform basis.
>>
>> 'latest version' is only one of the dimensions that we're interested
>> in. At this point in time, there are really three version dimensions
>> that are interesting:
>>
>>   bleedingEdge - the latest mcz file defined in the latest baseline
>> for a
>>                         project.
>>   development - the currently active development version
>>   stable           - what we really want when we say 'latest version'
>>
>> I expect that over time there will be additional dimensions over time.
>> For Metacello I've already played with #earlyAccess versions which are
>> 'stable' development versions.
>>
>> The requirement is to be able to declare a #stable or #development
>> version on a platform by platform basis. So we've added an two
>> additional pragmas that can be included in Configuration class
>> methods:
>>
>>   <symbolicVersion: SYMBOLIC_VERSION_SYMBOL>
>>   <defaultSymbolicVersion: SYMBOLIC_VERSION_SYMBOL>
>>
>> The #symbolicVersion: pragma is similar to the version pragma
>> (<version: VERSION_STRING>). The following is an example where a set
>> of #stable symbolic versions are declared:
>>
>>   stable: spec
>>        <symbolicVersion: #'stable'>
>>
>>        spec for: #'common' version: '1.0.2.1'.
>>        spec for: #'pharo1.0.x' version: '1.0.2.1'.
>>        spec for: #'pharo1.1.x' version: '1.0.3'.
>>        spec for: #'pharo1.2.x' version: '1.0.4'.
>>
>> The #defaultSymbolicVersion: is used in a method that is expected to
>> be regular smalltalk code that returns a version string. The following
>> is the definition for the #bleedingEdge symbolic version:
>>
>>   bleedingEdge
>>        <defaultSymbolicVersion: #bleedingEdge>
>>
>>        | bleedingEdgeVersion |
>>        bleedingEdgeVersion := (self project map values select: [ :version |
>> version blessing == #baseline ])
>>                detectMax: [ :version | version ].
>>        bleedingEdgeVersion ifNil: [ bleedingEdgeVersion := self project
>> latestVersion ].
>>        bleedingEdgeVersion
>>                ifNil: [ self versionDoesNotExistError: #bleedingEdge ].
>>        ^ bleedingEdgeVersion versionString
>>
>> When specifying a symbolic version with a #symbolicVersion: pragma it
>> is legal to use another symbolic version like the following definition
>> for the symbolic version #stable:
>>
>>   stable: spec
>>        <symbolicVersion: #'stable'>
>>
>>        spec for: #'gemstone' version: '1.5'.
>>        spec for: #'squeak' version: '1.4'.
>>        spec for: #'pharo1.0.x' version: '1.5'.
>>        spec for: #'pharo1.1.x' version: '1.5'.
>>        spec for: #'pharo1.2.x' version: #development.
>>
>> Or to use the special symbolic version #notDefined: as in the
>> following definition of the symbolic version #development:
>>
>>   development: spec
>>        <symbolicVersion: #'development'>
>>
>>        spec for: #'common' version: #notDefined.
>>        spec for: #'pharo1.1.x' version: '1.6'.
>>        spec for: #'pharo1.2.x' version: '1.6'.
>>
>> Using a symbolic version that resolves to #notDefined will result in a
>> MetacelloSymbolicVersionNotDefinedError being signalled.
>>
>> A symbolic version may be used anywhere that a literal version may be
>> used.
>>
>> Well, this should cover the basics...
>>
>> Dale
>>
>> On Nov 25, 3:21 am, Alexandre Bergel<[hidden email]>  wrote:
>>> Is there a short description of symbolic versions somewhere?
>>>
>>> Alexandre
>>>
>>> On 24 Nov 2010, at 21:46, Dale wrote:
>>>
>>>
>>>
>>>> Over the last few days I've been working on converting
>>>> ConfigurationOfOmniBrowser and the configurations it depends upon
>>>> (ConfigurationOfRefactoringBrowser, ConfigurationOfShout, and
>>>> ConfigurationOfOCompletion) to use symbolic versions.
>>>
>>>> The results are stashed away in a repository on the Bibliocello site:
>>>
>>>>   http://a-bibliocello.gemstone.com/bibliocello/projects/Pharo/reposito...
>>>
>>>> With Metacello 1.0-beta.28 loaded you can execute the following
>>>> expression in a PharoCore1.0, PharoCore1.1, or PharoCore1.2 image and
>>>> the appropriate versions of OmniBrowser and the supporting proejcts
>>>> will be loaded:
>>>
>>>>   (ConfigurationOfOmniBrowser project version: #stable) load: 'Tests'.
>>>
>>>> So far I have  been using only the 'Tests' group because ... well I
>>>> want to verify that the code not only loads, but passes all of the
>>>> tests (for the loaded projects) in each image and the results are:
>>>
>>>>   PharoCore1.0:
>>>>     1221 run, 1218 passes, 3 expected failures,
>>>>       0 failures, 0 errors, 0 unexpected passes
>>>>   PharoCore1.1:
>>>>     1325 run, 1324 passes, 1 expected failures,
>>>>       0 failures, 0 errors, 0 unexpected passes
>>>>   PharoCore1.2:
>>>>     814 run, 813 expected passes,
>>>>       0 expected failures, 0 failures, 1 errors, 0 unexpected passes,
>>>>       and deprecation warnings
>>>
>>>> For Pharo1.2, OB-Refactory is not loaded, because it doesn't appear to
>>>> have been ported to Pharo1.2 yet ...
>>>
>>>> If you want to look at what I've done you can compare the latest
>>>> version of the config with the earliest version of the config in the
>>>> repository ... I'll be glad to explain any changes that don't make
>>>> sense to you.
>>>
>>>> All four configs also run clean against the Metacello validator ....
>>>
>>>> I've developed a set of scripts (in MetacelloToolBox) that I have been
>>>> using to automate the process of determining which versions in a
>>>> particular configuration load cleanly into an image and if the tests
>>>> pass as well (including checking for deprecation warnings). The
>>>> following expression when executed in a PharoCore1.0.x image will load
>>>> each version in the configuration and run the tests (loading the
>>>> 'Tests' group if it is defined):
>>>
>>>>   (MetacelloToolBox
>>>>     validatePlatformLoad: #'pharo1.0.x' for: 'OmniBrowser') explore.
>>>
>>>> Right now, that script will automatically update the development and
>>>> stable symbolic version definitions as well as mark versions as
>>>> #release if the 'Tests' group loads without errors or deprecation
>>>> warnings and passes all of the tests (without deprecation warnings).
>>>> It also produces an 'issues list' that describes the individual
>>>> errors, critical warnings and warnings for each version ... much like
>>>> the validator with added information about tests.
>>>
>>>> I expect to continue working my way through the various configurations
>>>> with the goal to automate as much of the validation and analysis as
>>>> possible...
>>>
>>>> Dale
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

> Alexandre,
>
> What you are suggesting is that there would need to be multiple mappings for the versions 'default' and '2.1.2'...
>
> the problem that we have right now is that '2.1.2' doesn't work in Pharo1.0 (but version '1.2' does), but works in Pharo1.2 (for example).
>
> So we have _different_ versions that apply to different platforms so the solution is to allow a developer to map a version to a platform...
>
> With symbolic versions we still have multiple mappings for the symbolic version, but they are intended from the outset to have multiple mappings and the different is clear.
>
> Dale
>
>
> On 11/25/2010 12:23 PM, Alexandre Bergel wrote:
>> Ok. But why not simply having
>> ConfigurationOfMondrian class>>  loadForPharo12
>>   (self project version: 'default') load
>>
>> ConfigurationOfMondrian loadForPharo111
>>   (self project version: '2.1.2') load
>>
>> ?
>>
>> Alexandre
>>
>> On 25 Nov 2010, at 13:44, Dale wrote:
>>
>>> Alexandre,
>>>
>>> Not yet ... I'm still expecting to tweak a thing or two with symbolic
>>> versions, but I can take a crack at a short description of what I've
>>> got so far.
>>>
>>> From the beginning Metacello has had the notion of loading the latest
>>> version. The expectation was that loading the latest release would
>>> always be the best thing to do.
>>>
>>> As Pharo has moved forward, aggressively cleaning up the base image,
>>> it has turned out that loading the latest version isn't always the
>>> best solution:
>>>
>>>  - code that runs in Pharo1.0 won't work in Pharo1.2 and vice versa
>>>
>>> To solve this problem we need to be able to describe the 'latest
>>> version' on a platform by platform basis.
>>>
>>> 'latest version' is only one of the dimensions that we're interested
>>> in. At this point in time, there are really three version dimensions
>>> that are interesting:
>>>
>>>  bleedingEdge - the latest mcz file defined in the latest baseline
>>> for a
>>>                        project.
>>>  development - the currently active development version
>>>  stable           - what we really want when we say 'latest version'
>>>
>>> I expect that over time there will be additional dimensions over time.
>>> For Metacello I've already played with #earlyAccess versions which are
>>> 'stable' development versions.
>>>
>>> The requirement is to be able to declare a #stable or #development
>>> version on a platform by platform basis. So we've added an two
>>> additional pragmas that can be included in Configuration class
>>> methods:
>>>
>>>  <symbolicVersion: SYMBOLIC_VERSION_SYMBOL>
>>>  <defaultSymbolicVersion: SYMBOLIC_VERSION_SYMBOL>
>>>
>>> The #symbolicVersion: pragma is similar to the version pragma
>>> (<version: VERSION_STRING>). The following is an example where a set
>>> of #stable symbolic versions are declared:
>>>
>>>  stable: spec
>>>       <symbolicVersion: #'stable'>
>>>
>>>       spec for: #'common' version: '1.0.2.1'.
>>>       spec for: #'pharo1.0.x' version: '1.0.2.1'.
>>>       spec for: #'pharo1.1.x' version: '1.0.3'.
>>>       spec for: #'pharo1.2.x' version: '1.0.4'.
>>>
>>> The #defaultSymbolicVersion: is used in a method that is expected to
>>> be regular smalltalk code that returns a version string. The following
>>> is the definition for the #bleedingEdge symbolic version:
>>>
>>>  bleedingEdge
>>>       <defaultSymbolicVersion: #bleedingEdge>
>>>
>>>       | bleedingEdgeVersion |
>>>       bleedingEdgeVersion := (self project map values select: [ :version |
>>> version blessing == #baseline ])
>>>               detectMax: [ :version | version ].
>>>       bleedingEdgeVersion ifNil: [ bleedingEdgeVersion := self project
>>> latestVersion ].
>>>       bleedingEdgeVersion
>>>               ifNil: [ self versionDoesNotExistError: #bleedingEdge ].
>>>       ^ bleedingEdgeVersion versionString
>>>
>>> When specifying a symbolic version with a #symbolicVersion: pragma it
>>> is legal to use another symbolic version like the following definition
>>> for the symbolic version #stable:
>>>
>>>  stable: spec
>>>       <symbolicVersion: #'stable'>
>>>
>>>       spec for: #'gemstone' version: '1.5'.
>>>       spec for: #'squeak' version: '1.4'.
>>>       spec for: #'pharo1.0.x' version: '1.5'.
>>>       spec for: #'pharo1.1.x' version: '1.5'.
>>>       spec for: #'pharo1.2.x' version: #development.
>>>
>>> Or to use the special symbolic version #notDefined: as in the
>>> following definition of the symbolic version #development:
>>>
>>>  development: spec
>>>       <symbolicVersion: #'development'>
>>>
>>>       spec for: #'common' version: #notDefined.
>>>       spec for: #'pharo1.1.x' version: '1.6'.
>>>       spec for: #'pharo1.2.x' version: '1.6'.
>>>
>>> Using a symbolic version that resolves to #notDefined will result in a
>>> MetacelloSymbolicVersionNotDefinedError being signalled.
>>>
>>> A symbolic version may be used anywhere that a literal version may be
>>> used.
>>>
>>> Well, this should cover the basics...
>>>
>>> Dale
>>>
>>> On Nov 25, 3:21 am, Alexandre Bergel<[hidden email]>  wrote:
>>>> Is there a short description of symbolic versions somewhere?
>>>>
>>>> Alexandre
>>>>
>>>> On 24 Nov 2010, at 21:46, Dale wrote:
>>>>
>>>>
>>>>
>>>>> Over the last few days I've been working on converting
>>>>> ConfigurationOfOmniBrowser and the configurations it depends upon
>>>>> (ConfigurationOfRefactoringBrowser, ConfigurationOfShout, and
>>>>> ConfigurationOfOCompletion) to use symbolic versions.
>>>>
>>>>> The results are stashed away in a repository on the Bibliocello site:
>>>>
>>>>>  http://a-bibliocello.gemstone.com/bibliocello/projects/Pharo/reposito...
>>>>
>>>>> With Metacello 1.0-beta.28 loaded you can execute the following
>>>>> expression in a PharoCore1.0, PharoCore1.1, or PharoCore1.2 image and
>>>>> the appropriate versions of OmniBrowser and the supporting proejcts
>>>>> will be loaded:
>>>>
>>>>>  (ConfigurationOfOmniBrowser project version: #stable) load: 'Tests'.
>>>>
>>>>> So far I have  been using only the 'Tests' group because ... well I
>>>>> want to verify that the code not only loads, but passes all of the
>>>>> tests (for the loaded projects) in each image and the results are:
>>>>
>>>>>  PharoCore1.0:
>>>>>    1221 run, 1218 passes, 3 expected failures,
>>>>>      0 failures, 0 errors, 0 unexpected passes
>>>>>  PharoCore1.1:
>>>>>    1325 run, 1324 passes, 1 expected failures,
>>>>>      0 failures, 0 errors, 0 unexpected passes
>>>>>  PharoCore1.2:
>>>>>    814 run, 813 expected passes,
>>>>>      0 expected failures, 0 failures, 1 errors, 0 unexpected passes,
>>>>>      and deprecation warnings
>>>>
>>>>> For Pharo1.2, OB-Refactory is not loaded, because it doesn't appear to
>>>>> have been ported to Pharo1.2 yet ...
>>>>
>>>>> If you want to look at what I've done you can compare the latest
>>>>> version of the config with the earliest version of the config in the
>>>>> repository ... I'll be glad to explain any changes that don't make
>>>>> sense to you.
>>>>
>>>>> All four configs also run clean against the Metacello validator ....
>>>>
>>>>> I've developed a set of scripts (in MetacelloToolBox) that I have been
>>>>> using to automate the process of determining which versions in a
>>>>> particular configuration load cleanly into an image and if the tests
>>>>> pass as well (including checking for deprecation warnings). The
>>>>> following expression when executed in a PharoCore1.0.x image will load
>>>>> each version in the configuration and run the tests (loading the
>>>>> 'Tests' group if it is defined):
>>>>
>>>>>  (MetacelloToolBox
>>>>>    validatePlatformLoad: #'pharo1.0.x' for: 'OmniBrowser') explore.
>>>>
>>>>> Right now, that script will automatically update the development and
>>>>> stable symbolic version definitions as well as mark versions as
>>>>> #release if the 'Tests' group loads without errors or deprecation
>>>>> warnings and passes all of the tests (without deprecation warnings).
>>>>> It also produces an 'issues list' that describes the individual
>>>>> errors, critical warnings and warnings for each version ... much like
>>>>> the validator with added information about tests.
>>>>
>>>>> I expect to continue working my way through the various configurations
>>>>> with the goal to automate as much of the validation and analysis as
>>>>> possible...
>>>>
>>>>> Dale
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>

> Are you suggesting that we may have two 2.1.2 versions, each for a particular platform? I feel I can get easily confused with that :-)
>
> Cheers,
> Alexandre
>
> On 25 Nov 2010, at 17:46, Dale Henrichs wrote:
>
>
>
> > Alexandre,
>
> > What you are suggesting is that there would need to be multiple mappings for the versions 'default' and '2.1.2'...
>
> > the problem that we have right now is that '2.1.2' doesn't work in Pharo1.0 (but version '1.2' does), but works in Pharo1.2 (for example).
>
> > So we have _different_ versions that apply to different platforms so the solution is to allow a developer to map a version to a platform...
>
> > With symbolic versions we still have multiple mappings for the symbolic version, but they are intended from the outset to have multiple mappings and the different is clear.
>
> > Dale
>
> > On 11/25/2010 12:23 PM, Alexandre Bergel wrote:
> >> Ok. But why not simply having
> >> ConfigurationOfMondrian class>>  loadForPharo12
> >>   (self project version: 'default') load
>
> >> ConfigurationOfMondrian loadForPharo111
> >>   (self project version: '2.1.2') load
>
> >> ?
>
> >> Alexandre
>
> >> On 25 Nov 2010, at 13:44, Dale wrote:
>
> >>> Alexandre,
>
> >>> Not yet ... I'm still expecting to tweak a thing or two with symbolic
> >>> versions, but I can take a crack at a short description of what I've
> >>> got so far.
>
> >>> From the beginning Metacello has had the notion of loading the latest
> >>> version. The expectation was that loading the latest release would
> >>> always be the best thing to do.
>
> >>> As Pharo has moved forward, aggressively cleaning up the base image,
> >>> it has turned out that loading the latest version isn't always the
> >>> best solution:
>
> >>>  - code that runs in Pharo1.0 won't work in Pharo1.2 and vice versa
>
> >>> To solve this problem we need to be able to describe the 'latest
> >>> version' on a platform by platform basis.
>
> >>> 'latest version' is only one of the dimensions that we're interested
> >>> in. At this point in time, there are really three version dimensions
> >>> that are interesting:
>
> >>>  bleedingEdge - the latest mcz file defined in the latest baseline
> >>> for a
> >>>                        project.
> >>>  development - the currently active development version
> >>>  stable           - what we really want when we say 'latest version'
>
> >>> I expect that over time there will be additional dimensions over time.
> >>> For Metacello I've already played with #earlyAccess versions which are
> >>> 'stable' development versions.
>
> >>> The requirement is to be able to declare a #stable or #development
> >>> version on a platform by platform basis. So we've added an two
> >>> additional pragmas that can be included in Configuration class
> >>> methods:
>
> >>>  <symbolicVersion: SYMBOLIC_VERSION_SYMBOL>
> >>>  <defaultSymbolicVersion: SYMBOLIC_VERSION_SYMBOL>
>
> >>> The #symbolicVersion: pragma is similar to the version pragma
> >>> (<version: VERSION_STRING>). The following is an example where a set
> >>> of #stable symbolic versions are declared:
>
> >>>  stable: spec
> >>>       <symbolicVersion: #'stable'>
>
> >>>       spec for: #'common' version: '1.0.2.1'.
> >>>       spec for: #'pharo1.0.x' version: '1.0.2.1'.
> >>>       spec for: #'pharo1.1.x' version: '1.0.3'.
> >>>       spec for: #'pharo1.2.x' version: '1.0.4'.
>
> >>> The #defaultSymbolicVersion: is used in a method that is expected to
> >>> be regular smalltalk code that returns a version string. The following
> >>> is the definition for the #bleedingEdge symbolic version:
>
> >>>  bleedingEdge
> >>>       <defaultSymbolicVersion: #bleedingEdge>
>
> >>>       | bleedingEdgeVersion |
> >>>       bleedingEdgeVersion := (self project map values select: [ :version |
> >>> version blessing == #baseline ])
> >>>               detectMax: [ :version | version ].
> >>>       bleedingEdgeVersion ifNil: [ bleedingEdgeVersion := self project
> >>> latestVersion ].
> >>>       bleedingEdgeVersion
> >>>               ifNil: [ self versionDoesNotExistError: #bleedingEdge ].
> >>>       ^ bleedingEdgeVersion versionString
>
> >>> When specifying a symbolic version with a #symbolicVersion: pragma it
> >>> is legal to use another symbolic version like the following definition
> >>> for the symbolic version #stable:
>
> >>>  stable: spec
> >>>       <symbolicVersion: #'stable'>
>
> >>>       spec for: #'gemstone' version: '1.5'.
> >>>       spec for: #'squeak' version: '1.4'.
> >>>       spec for: #'pharo1.0.x' version: '1.5'.
> >>>       spec for: #'pharo1.1.x' version: '1.5'.
> >>>       spec for: #'pharo1.2.x' version: #development.
>
> >>> Or to use the special symbolic version #notDefined: as in the
> >>> following definition of the symbolic version #development:
>
> >>>  development: spec
> >>>       <symbolicVersion: #'development'>
>
> >>>       spec for: #'common' version: #notDefined.
> >>>       spec for: #'pharo1.1.x' version: '1.6'.
> >>>       spec for: #'pharo1.2.x' version: '1.6'.
>
> >>> Using a symbolic version that resolves to #notDefined will result in a
> >>> MetacelloSymbolicVersionNotDefinedError being signalled.
>
> >>> A symbolic version may be used anywhere that a literal version may be
> >>> used.
>
> >>> Well, this should cover the basics...
>
> >>> Dale
>
> >>> On Nov 25, 3:21 am, Alexandre Bergel<[hidden email]>  wrote:
> >>>> Is there a short description of symbolic versions somewhere?
>
> >>>> Alexandre
>
> >>>> On 24 Nov 2010, at 21:46, Dale wrote:
>
> >>>>> Over the last few days I've been working on converting
> >>>>> ConfigurationOfOmniBrowser and the configurations it depends upon
> >>>>> (ConfigurationOfRefactoringBrowser, ConfigurationOfShout, and
> >>>>> ConfigurationOfOCompletion) to use symbolic versions.
>
> >>>>> The results are stashed away in a repository on the Bibliocello site:
>
> >>>>>  http://a-bibliocello.gemstone.com/bibliocello/projects/Pharo/reposito...
>
> >>>>> With Metacello 1.0-beta.28 loaded you can execute the following
> >>>>> expression in a PharoCore1.0, PharoCore1.1, or PharoCore1.2 image and
> >>>>> the appropriate versions of OmniBrowser and the supporting proejcts
> >>>>> will be loaded:
>
> >>>>>  (ConfigurationOfOmniBrowser project version: #stable) load: 'Tests'.
>
> >>>>> So far I have  been using only the 'Tests' group because ... well I
> >>>>> want to verify that the code not only loads, but passes all of the
> >>>>> tests (for the loaded projects) in each image and the results are:
>
> >>>>>  PharoCore1.0:
> >>>>>    1221 run, 1218 passes, 3 expected failures,
> >>>>>      0 failures, 0 errors, 0 unexpected passes
> >>>>>  PharoCore1.1:
> >>>>>    1325 run, 1324 passes, 1 expected failures,
> >>>>>      0 failures, 0 errors, 0 unexpected passes
> >>>>>  PharoCore1.2:
> >>>>>    814 run, 813 expected passes,
> >>>>>      0 expected failures, 0 failures, 1 errors, 0 unexpected passes,
> >>>>>      and deprecation warnings
>
> >>>>> For Pharo1.2, OB-Refactory is not loaded, because it doesn't appear to
> >>>>> have been ported to Pharo1.2 yet ...
>
> >>>>> If you want to look at what I've done you can compare the latest
> >>>>> version of the config with the earliest version of the config in the
> >>>>> repository ... I'll be glad to explain any changes that don't make
> >>>>> sense to you.
>
> >>>>> All four configs also run clean against the Metacello validator ....
>
> >>>>> I've developed a set of scripts (in MetacelloToolBox) that I have been
> >>>>> using to automate the process of determining which versions in a
> >>>>> particular configuration load cleanly into an image and if the tests
> >>>>> pass as well (including checking for deprecation warnings). The
> >>>>> following expression when executed in a PharoCore1.0.x image will load
> >>>>> each version in the configuration and run the tests (loading the
> >>>>> 'Tests' group if it is defined):
>
> >>>>>  (MetacelloToolBox
> >>>>>    validatePlatformLoad: #'pharo1.0.x' for: 'OmniBrowser') explore.
>
> >>>>> Right now, that script will automatically update the development and
> >>>>> stable symbolic version definitions as well as mark versions as
> >>>>> #release if the 'Tests' group loads without errors or deprecation
> >>>>> warnings and passes all of the tests (without deprecation warnings).
> >>>>> It also produces an 'issues list' that describes the individual
> >>>>> errors, critical warnings and warnings for each version ... much like
> >>>>> the validator with added information about tests.
>
> >>>>> I expect to continue working my way through the various configurations
> >>>>> with the goal to automate as much of the validation and analysis as
> >>>>> possible...
>
> >>>>> Dale
>
> >>>> --
> >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> >>>> Alexandre Bergel  http://www.bergel.eu
> >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
> >> --
> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> >> Alexandre Bergel  http://www.bergel.eu
> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

> Doru,
>
> If you want to try out the load you need to do a couple of things:
>
>  Gofer new
> gemsource: 'metacello';
> package: 'ConfigurationOfMetacello';
> load.
>
> Then:
>
>  (ConfigurationOfMetacello project version: '1.0-beta.28') load.
>
> Followed by:
>
>  Gofer new
> url: 'http://a-bibliocello.gemstone.com/bibliocello/projects/Pharo/
> repository/Experiment1/MetacelloRepository';
> package: 'ConfigurationOfGofer';
> package: 'ConfigurationOfRefactoringBrowser';
> package: 'ConfigurationOfShout';
> package: 'ConfigurationOfOCompletion';
> package: 'ConfigurationOfOmniBrowser';
> load.
>
> That way you've got all of the new configurations preloaded in your
> image. And then:
>
>  (ConfigurationOfOmniBrowser project version: #stable) load.
>
> Sorry about not including these instructions in the original message:(
>
> Dale
>
> On Nov 25, 5:10 am, Tudor Girba <[hidden email]> wrote:
>> Hi,
>>
>> I tried:
>> Gofer new
>>         url: 'http://a-bibliocello.gemstone.com/bibliocello/projects/Pharo/reposito...
>>         package: 'ConfigurationOfOmniBrowser';
>>         load.
>>  ((Smalltalk at: #ConfigurationOfOmniBrowser) project version: #stable) load: 'Tests'.
>>
>> But the (ConfigurationOfOmniBrowser project version: #stable) is nil.
>>
>> Cheers,
>> Doru
>>
>> On 25 Nov 2010, at 12:21, Alexandre Bergel wrote:
>>
>>
>>
>>> Is there a short description of symbolic versions somewhere?
>>
>>> Alexandre
>>
>>> On 24 Nov 2010, at 21:46, Dale wrote:
>>
>>>> Over the last few days I've been working on converting
>>>> ConfigurationOfOmniBrowser and the configurations it depends upon
>>>> (ConfigurationOfRefactoringBrowser, ConfigurationOfShout, and
>>>> ConfigurationOfOCompletion) to use symbolic versions.
>>
>>>> The results are stashed away in a repository on the Bibliocello site:
>>
>>>> http://a-bibliocello.gemstone.com/bibliocello/projects/Pharo/reposito...
>>
>>>> With Metacello 1.0-beta.28 loaded you can execute the following
>>>> expression in a PharoCore1.0, PharoCore1.1, or PharoCore1.2 image and
>>>> the appropriate versions of OmniBrowser and the supporting proejcts
>>>> will be loaded:
>>
>>>> (ConfigurationOfOmniBrowser project version: #stable) load: 'Tests'.
>>
>>>> So far I have  been using only the 'Tests' group because ... well I
>>>> want to verify that the code not only loads, but passes all of the
>>>> tests (for the loaded projects) in each image and the results are:
>>
>>>> PharoCore1.0:
>>>>   1221 run, 1218 passes, 3 expected failures,
>>>>     0 failures, 0 errors, 0 unexpected passes
>>>> PharoCore1.1:
>>>>   1325 run, 1324 passes, 1 expected failures,
>>>>     0 failures, 0 errors, 0 unexpected passes
>>>> PharoCore1.2:
>>>>   814 run, 813 expected passes,
>>>>     0 expected failures, 0 failures, 1 errors, 0 unexpected passes,
>>>>     and deprecation warnings
>>
>>>> For Pharo1.2, OB-Refactory is not loaded, because it doesn't appear to
>>>> have been ported to Pharo1.2 yet ...
>>
>>>> If you want to look at what I've done you can compare the latest
>>>> version of the config with the earliest version of the config in the
>>>> repository ... I'll be glad to explain any changes that don't make
>>>> sense to you.
>>
>>>> All four configs also run clean against the Metacello validator ....
>>
>>>> I've developed a set of scripts (in MetacelloToolBox) that I have been
>>>> using to automate the process of determining which versions in a
>>>> particular configuration load cleanly into an image and if the tests
>>>> pass as well (including checking for deprecation warnings). The
>>>> following expression when executed in a PharoCore1.0.x image will load
>>>> each version in the configuration and run the tests (loading the
>>>> 'Tests' group if it is defined):
>>
>>>> (MetacelloToolBox
>>>>        validatePlatformLoad: #'pharo1.0.x' for: 'OmniBrowser') explore.
>>
>>>> Right now, that script will automatically update the development and
>>>> stable symbolic version definitions as well as mark versions as
>>>> #release if the 'Tests' group loads without errors or deprecation
>>>> warnings and passes all of the tests (without deprecation warnings).
>>>> It also produces an 'issues list' that describes the individual
>>>> errors, critical warnings and warnings for each version ... much like
>>>> the validator with added information about tests.
>>
>>>> I expect to continue working my way through the various configurations
>>>> with the goal to automate as much of the validation and analysis as
>>>> possible...
>>
>>>> Dale
>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>> --www.tudorgirba.com
>>
>> "In a world where everything is moving ever faster,
>> one might have better chances to win by moving slower."

> Hi Dale,
>
> I followed your instructions. The version loaded, but the version is not stable because I cannot spawn a browser :). Or am I doing something wrong?
>
> Cheers,
> Doru
>
>
> On 25 Nov 2010, at 17:02, Dale wrote:
>
>> Doru,
>>
>> If you want to try out the load you need to do a couple of things:
>>
>>   Gofer new
>> gemsource: 'metacello';
>> package: 'ConfigurationOfMetacello';
>> load.
>>
>> Then:
>>
>>   (ConfigurationOfMetacello project version: '1.0-beta.28') load.
>>
>> Followed by:
>>
>>   Gofer new
>> url: 'http://a-bibliocello.gemstone.com/bibliocello/projects/Pharo/
>> repository/Experiment1/MetacelloRepository';
>> package: 'ConfigurationOfGofer';
>> package: 'ConfigurationOfRefactoringBrowser';
>> package: 'ConfigurationOfShout';
>> package: 'ConfigurationOfOCompletion';
>> package: 'ConfigurationOfOmniBrowser';
>> load.
>>
>> That way you've got all of the new configurations preloaded in your
>> image. And then:
>>
>>   (ConfigurationOfOmniBrowser project version: #stable) load.
>>
>> Sorry about not including these instructions in the original message:(
>>
>> Dale
>>
>> On Nov 25, 5:10 am, Tudor Girba<[hidden email]>  wrote:
>>> Hi,
>>>
>>> I tried:
>>> Gofer new
>>>          url: 'http://a-bibliocello.gemstone.com/bibliocello/projects/Pharo/reposito...
>>>          package: 'ConfigurationOfOmniBrowser';
>>>          load.
>>>   ((Smalltalk at: #ConfigurationOfOmniBrowser) project version: #stable) load: 'Tests'.
>>>
>>> But the (ConfigurationOfOmniBrowser project version: #stable) is nil.
>>>
>>> Cheers,
>>> Doru
>>>
>>> On 25 Nov 2010, at 12:21, Alexandre Bergel wrote:
>>>
>>>
>>>
>>>> Is there a short description of symbolic versions somewhere?
>>>
>>>> Alexandre
>>>
>>>> On 24 Nov 2010, at 21:46, Dale wrote:
>>>
>>>>> Over the last few days I've been working on converting
>>>>> ConfigurationOfOmniBrowser and the configurations it depends upon
>>>>> (ConfigurationOfRefactoringBrowser, ConfigurationOfShout, and
>>>>> ConfigurationOfOCompletion) to use symbolic versions.
>>>
>>>>> The results are stashed away in a repository on the Bibliocello site:
>>>
>>>>> http://a-bibliocello.gemstone.com/bibliocello/projects/Pharo/reposito...
>>>
>>>>> With Metacello 1.0-beta.28 loaded you can execute the following
>>>>> expression in a PharoCore1.0, PharoCore1.1, or PharoCore1.2 image and
>>>>> the appropriate versions of OmniBrowser and the supporting proejcts
>>>>> will be loaded:
>>>
>>>>> (ConfigurationOfOmniBrowser project version: #stable) load: 'Tests'.
>>>
>>>>> So far I have  been using only the 'Tests' group because ... well I
>>>>> want to verify that the code not only loads, but passes all of the
>>>>> tests (for the loaded projects) in each image and the results are:
>>>
>>>>> PharoCore1.0:
>>>>>    1221 run, 1218 passes, 3 expected failures,
>>>>>      0 failures, 0 errors, 0 unexpected passes
>>>>> PharoCore1.1:
>>>>>    1325 run, 1324 passes, 1 expected failures,
>>>>>      0 failures, 0 errors, 0 unexpected passes
>>>>> PharoCore1.2:
>>>>>    814 run, 813 expected passes,
>>>>>      0 expected failures, 0 failures, 1 errors, 0 unexpected passes,
>>>>>      and deprecation warnings
>>>
>>>>> For Pharo1.2, OB-Refactory is not loaded, because it doesn't appear to
>>>>> have been ported to Pharo1.2 yet ...
>>>
>>>>> If you want to look at what I've done you can compare the latest
>>>>> version of the config with the earliest version of the config in the
>>>>> repository ... I'll be glad to explain any changes that don't make
>>>>> sense to you.
>>>
>>>>> All four configs also run clean against the Metacello validator ....
>>>
>>>>> I've developed a set of scripts (in MetacelloToolBox) that I have been
>>>>> using to automate the process of determining which versions in a
>>>>> particular configuration load cleanly into an image and if the tests
>>>>> pass as well (including checking for deprecation warnings). The
>>>>> following expression when executed in a PharoCore1.0.x image will load
>>>>> each version in the configuration and run the tests (loading the
>>>>> 'Tests' group if it is defined):
>>>
>>>>> (MetacelloToolBox
>>>>>         validatePlatformLoad: #'pharo1.0.x' for: 'OmniBrowser') explore.
>>>
>>>>> Right now, that script will automatically update the development and
>>>>> stable symbolic version definitions as well as mark versions as
>>>>> #release if the 'Tests' group loads without errors or deprecation
>>>>> warnings and passes all of the tests (without deprecation warnings).
>>>>> It also produces an 'issues list' that describes the individual
>>>>> errors, critical warnings and warnings for each version ... much like
>>>>> the validator with added information about tests.
>>>
>>>>> I expect to continue working my way through the various configurations
>>>>> with the goal to automate as much of the validation and analysis as
>>>>> possible...
>>>
>>>>> Dale
>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>> --www.tudorgirba.com
>>>
>>> "In a world where everything is moving ever faster,
>>> one might have better chances to win by moving slower."
>
> --
> www.tudorgirba.com
>
> "Some battles are better lost than fought."
>
>
>

> I am not suggesting that. What you are proposing implies that there
> are two 2.1.2 versions.
>
> I am suggesting that by using symbolic versions you can specify that:
>
>  version 1.2 is the stable version for Pharo1.0
>  version 2.1.2 is the stable version for Pharo1.2
>
> by loading the #stable version the correct version will be loaded
> based upon the platform you are loading on ...
>
> An additional advantage of symbolic versions is that a project
> reference can specify a symbolic version.
>
> For example, certain packages in Seaside30 depend upon OmniBrowser.
> Seaside30 itself has been written so that version 3.0.2 loads into
> Pharo1.0 and Pharo1.2 correctly.  There is no single version of
> OmniBrowser that loads correctly into both Pharo1.0 and Pharo1.2,
> which creates a bit of a problem for Seaside 30 users.
>
> With symbolic versions it is possible to specify that the #stable
> version of OmniBrowser be loaded by Seaside30. In so doing the correct
> (stable) version of OmniBrowser will be loaded by Seaside30 for the
> platform into which Seaside30 is being loaded ... there is no need to
> Seaside30 to worry about which platforms may be involved ... all that
> needs to be specified is that the #stable version be loaded.
>
> Dale
>
>
> On Nov 25, 1:24 pm, Alexandre Bergel <[hidden email]> wrote:
>> Are you suggesting that we may have two 2.1.2 versions, each for a particular platform? I feel I can get easily confused with that :-)
>>
>> Cheers,
>> Alexandre
>>
>> On 25 Nov 2010, at 17:46, Dale Henrichs wrote:
>>
>>
>>
>>> Alexandre,
>>
>>> What you are suggesting is that there would need to be multiple mappings for the versions 'default' and '2.1.2'...
>>
>>> the problem that we have right now is that '2.1.2' doesn't work in Pharo1.0 (but version '1.2' does), but works in Pharo1.2 (for example).
>>
>>> So we have _different_ versions that apply to different platforms so the solution is to allow a developer to map a version to a platform...
>>
>>> With symbolic versions we still have multiple mappings for the symbolic version, but they are intended from the outset to have multiple mappings and the different is clear.
>>
>>> Dale
>>
>>> On 11/25/2010 12:23 PM, Alexandre Bergel wrote:
>>>> Ok. But why not simply having
>>>> ConfigurationOfMondrian class>>  loadForPharo12
>>>>   (self project version: 'default') load
>>
>>>> ConfigurationOfMondrian loadForPharo111
>>>>   (self project version: '2.1.2') load
>>
>>>> ?
>>
>>>> Alexandre
>>
>>>> On 25 Nov 2010, at 13:44, Dale wrote:
>>
>>>>> Alexandre,
>>
>>>>> Not yet ... I'm still expecting to tweak a thing or two with symbolic
>>>>> versions, but I can take a crack at a short description of what I've
>>>>> got so far.
>>
>>>>> From the beginning Metacello has had the notion of loading the latest
>>>>> version. The expectation was that loading the latest release would
>>>>> always be the best thing to do.
>>
>>>>> As Pharo has moved forward, aggressively cleaning up the base image,
>>>>> it has turned out that loading the latest version isn't always the
>>>>> best solution:
>>
>>>>>  - code that runs in Pharo1.0 won't work in Pharo1.2 and vice versa
>>
>>>>> To solve this problem we need to be able to describe the 'latest
>>>>> version' on a platform by platform basis.
>>
>>>>> 'latest version' is only one of the dimensions that we're interested
>>>>> in. At this point in time, there are really three version dimensions
>>>>> that are interesting:
>>
>>>>>  bleedingEdge - the latest mcz file defined in the latest baseline
>>>>> for a
>>>>>                        project.
>>>>>  development - the currently active development version
>>>>>  stable           - what we really want when we say 'latest version'
>>
>>>>> I expect that over time there will be additional dimensions over time.
>>>>> For Metacello I've already played with #earlyAccess versions which are
>>>>> 'stable' development versions.
>>
>>>>> The requirement is to be able to declare a #stable or #development
>>>>> version on a platform by platform basis. So we've added an two
>>>>> additional pragmas that can be included in Configuration class
>>>>> methods:
>>
>>>>>  <symbolicVersion: SYMBOLIC_VERSION_SYMBOL>
>>>>>  <defaultSymbolicVersion: SYMBOLIC_VERSION_SYMBOL>
>>
>>>>> The #symbolicVersion: pragma is similar to the version pragma
>>>>> (<version: VERSION_STRING>). The following is an example where a set
>>>>> of #stable symbolic versions are declared:
>>
>>>>>  stable: spec
>>>>>       <symbolicVersion: #'stable'>
>>
>>>>>       spec for: #'common' version: '1.0.2.1'.
>>>>>       spec for: #'pharo1.0.x' version: '1.0.2.1'.
>>>>>       spec for: #'pharo1.1.x' version: '1.0.3'.
>>>>>       spec for: #'pharo1.2.x' version: '1.0.4'.
>>
>>>>> The #defaultSymbolicVersion: is used in a method that is expected to
>>>>> be regular smalltalk code that returns a version string. The following
>>>>> is the definition for the #bleedingEdge symbolic version:
>>
>>>>>  bleedingEdge
>>>>>       <defaultSymbolicVersion: #bleedingEdge>
>>
>>>>>       | bleedingEdgeVersion |
>>>>>       bleedingEdgeVersion := (self project map values select: [ :version |
>>>>> version blessing == #baseline ])
>>>>>               detectMax: [ :version | version ].
>>>>>       bleedingEdgeVersion ifNil: [ bleedingEdgeVersion := self project
>>>>> latestVersion ].
>>>>>       bleedingEdgeVersion
>>>>>               ifNil: [ self versionDoesNotExistError: #bleedingEdge ].
>>>>>       ^ bleedingEdgeVersion versionString
>>
>>>>> When specifying a symbolic version with a #symbolicVersion: pragma it
>>>>> is legal to use another symbolic version like the following definition
>>>>> for the symbolic version #stable:
>>
>>>>>  stable: spec
>>>>>       <symbolicVersion: #'stable'>
>>
>>>>>       spec for: #'gemstone' version: '1.5'.
>>>>>       spec for: #'squeak' version: '1.4'.
>>>>>       spec for: #'pharo1.0.x' version: '1.5'.
>>>>>       spec for: #'pharo1.1.x' version: '1.5'.
>>>>>       spec for: #'pharo1.2.x' version: #development.
>>
>>>>> Or to use the special symbolic version #notDefined: as in the
>>>>> following definition of the symbolic version #development:
>>
>>>>>  development: spec
>>>>>       <symbolicVersion: #'development'>
>>
>>>>>       spec for: #'common' version: #notDefined.
>>>>>       spec for: #'pharo1.1.x' version: '1.6'.
>>>>>       spec for: #'pharo1.2.x' version: '1.6'.
>>
>>>>> Using a symbolic version that resolves to #notDefined will result in a
>>>>> MetacelloSymbolicVersionNotDefinedError being signalled.
>>
>>>>> A symbolic version may be used anywhere that a literal version may be
>>>>> used.
>>
>>>>> Well, this should cover the basics...
>>
>>>>> Dale
>>
>>>>> On Nov 25, 3:21 am, Alexandre Bergel<[hidden email]>  wrote:
>>>>>> Is there a short description of symbolic versions somewhere?
>>
>>>>>> Alexandre
>>
>>>>>> On 24 Nov 2010, at 21:46, Dale wrote:
>>
>>>>>>> Over the last few days I've been working on converting
>>>>>>> ConfigurationOfOmniBrowser and the configurations it depends upon
>>>>>>> (ConfigurationOfRefactoringBrowser, ConfigurationOfShout, and
>>>>>>> ConfigurationOfOCompletion) to use symbolic versions.
>>
>>>>>>> The results are stashed away in a repository on the Bibliocello site:
>>
>>>>>>>  http://a-bibliocello.gemstone.com/bibliocello/projects/Pharo/reposito...
>>
>>>>>>> With Metacello 1.0-beta.28 loaded you can execute the following
>>>>>>> expression in a PharoCore1.0, PharoCore1.1, or PharoCore1.2 image and
>>>>>>> the appropriate versions of OmniBrowser and the supporting proejcts
>>>>>>> will be loaded:
>>
>>>>>>>  (ConfigurationOfOmniBrowser project version: #stable) load: 'Tests'.
>>
>>>>>>> So far I have  been using only the 'Tests' group because ... well I
>>>>>>> want to verify that the code not only loads, but passes all of the
>>>>>>> tests (for the loaded projects) in each image and the results are:
>>
>>>>>>>  PharoCore1.0:
>>>>>>>    1221 run, 1218 passes, 3 expected failures,
>>>>>>>      0 failures, 0 errors, 0 unexpected passes
>>>>>>>  PharoCore1.1:
>>>>>>>    1325 run, 1324 passes, 1 expected failures,
>>>>>>>      0 failures, 0 errors, 0 unexpected passes
>>>>>>>  PharoCore1.2:
>>>>>>>    814 run, 813 expected passes,
>>>>>>>      0 expected failures, 0 failures, 1 errors, 0 unexpected passes,
>>>>>>>      and deprecation warnings
>>
>>>>>>> For Pharo1.2, OB-Refactory is not loaded, because it doesn't appear to
>>>>>>> have been ported to Pharo1.2 yet ...
>>
>>>>>>> If you want to look at what I've done you can compare the latest
>>>>>>> version of the config with the earliest version of the config in the
>>>>>>> repository ... I'll be glad to explain any changes that don't make
>>>>>>> sense to you.
>>
>>>>>>> All four configs also run clean against the Metacello validator ....
>>
>>>>>>> I've developed a set of scripts (in MetacelloToolBox) that I have been
>>>>>>> using to automate the process of determining which versions in a
>>>>>>> particular configuration load cleanly into an image and if the tests
>>>>>>> pass as well (including checking for deprecation warnings). The
>>>>>>> following expression when executed in a PharoCore1.0.x image will load
>>>>>>> each version in the configuration and run the tests (loading the
>>>>>>> 'Tests' group if it is defined):
>>
>>>>>>>  (MetacelloToolBox
>>>>>>>    validatePlatformLoad: #'pharo1.0.x' for: 'OmniBrowser') explore.
>>
>>>>>>> Right now, that script will automatically update the development and
>>>>>>> stable symbolic version definitions as well as mark versions as
>>>>>>> #release if the 'Tests' group loads without errors or deprecation
>>>>>>> warnings and passes all of the tests (without deprecation warnings).
>>>>>>> It also produces an 'issues list' that describes the individual
>>>>>>> errors, critical warnings and warnings for each version ... much like
>>>>>>> the validator with added information about tests.
>>
>>>>>>> I expect to continue working my way through the various configurations
>>>>>>> with the goal to automate as much of the validation and analysis as
>>>>>>> possible...
>>
>>>>>>> Dale
>>
>>>>>> --
>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

> dale
>
> It would be really nice if you could take 10 min and extract a small but true example describing the problems
> like that we can paste it in the book chapter :)
> I'm sure other people will get confused.
> I think that the key point is to be able to specify that stable is relative to a platform version and that
> you do not have to write all the way such methods
>
> >>>> ConfigurationOfMondrian class>>  loadForPharo12
> >>>> (self project version: 'default') load
>
> >>>> ConfigurationOfMondrian loadForPharo111
> >>>> (self project version: '2.1.2') load
>
> this way you avoid ripple effect and get much more stable (non volatile) specs.
>
> Stef

> Stef, Alexandre,
>
> I know I'm missing something, but I'm not sure what:) I don't think I
> understand the confusing part...I know that I'm too close to the
> soution, so I'll appreciate your patience while you educate me a
> little bit more...
>
> Dale
>
> On Nov 26, 1:04 am, stephane ducasse <[hidden email]>
> wrote:
>> dale
>>
>> It would be really nice if you could take 10 min and extract a small but true example describing the problems
>> like that we can paste it in the book chapter :)
>> I'm sure other people will get confused.
>> I think that the key point is to be able to specify that stable is relative to a platform version and that
>> you do not have to write all the way such methods
>>
>>>>>> ConfigurationOfMondrian class>>  loadForPharo12
>>>>>> (self project version: 'default') load
>>
>>>>>> ConfigurationOfMondrian loadForPharo111
>>>>>> (self project version: '2.1.2') load
>>
>> this way you avoid ripple effect and get much more stable (non volatile) specs.
>>
>> Stef

> Stef, Alexandre,
>
> I know I'm missing something, but I'm not sure what:) I don't think I
> understand the confusing part...I know that I'm too close to the
> soution, so I'll appreciate your patience while you educate me a
> little bit more...
>
> Dale
>
> On Nov 26, 1:04 am, stephane ducasse <[hidden email]>
> wrote:
>> dale
>>
>> It would be really nice if you could take 10 min and extract a small but true example describing the problems
>> like that we can paste it in the book chapter :)
>> I'm sure other people will get confused.
>> I think that the key point is to be able to specify that stable is relative to a platform version and that
>> you do not have to write all the way such methods
>>
>>>>>> ConfigurationOfMondrian class>>  loadForPharo12
>>>>>> (self project version: 'default') load
>>
>>>>>> ConfigurationOfMondrian loadForPharo111
>>>>>> (self project version: '2.1.2') load
>>
>> this way you avoid ripple effect and get much more stable (non volatile) specs.
>>
>> Stef

> Personally, the biggest problem I have with Metacello, is that when something is going wrong, the error messages are not that useful. Several times I had to ask you and the mailing list to know what's going wrong. I had started to work on a support for Metacello in the Monticello browser. I use it and it helps me.
>
> Supporting version to platform mapping is important (we are currently being bitten by this). But I spend more time on getting a configuration right than missing the mapping.
>
> This is just my personal feeling and opinion.
>
> Cheers,
> Alexandre
>
>
> On 26 Nov 2010, at 14:06, Dale wrote:
>
>> Stef, Alexandre,
>>
>> I know I'm missing something, but I'm not sure what:) I don't think I
>> understand the confusing part...I know that I'm too close to the
>> soution, so I'll appreciate your patience while you educate me a
>> little bit more...
>>
>> Dale
>>
>> On Nov 26, 1:04 am, stephane ducasse<[hidden email]>
>> wrote:
>>> dale
>>>
>>> It would be really nice if you could take 10 min and extract a small but true example describing the problems
>>> like that we can paste it in the book chapter :)
>>> I'm sure other people will get confused.
>>> I think that the key point is to be able to specify that stable is relative to a platform version and that
>>> you do not have to write all the way such methods
>>>
>>>>>>> ConfigurationOfMondrian class>>   loadForPharo12
>>>>>>> (self project version: 'default') load
>>>
>>>>>>> ConfigurationOfMondrian loadForPharo111
>>>>>>> (self project version: '2.1.2') load
>>>
>>> this way you avoid ripple effect and get much more stable (non volatile) specs.
>>>
>>> Stef
>

> Hi,
>
> Let me try an explanation.
>
> Metacello versions are used for versioning your configurations.
>
> However, these numbers do not have any meaning regarding the intended use and context. For example, when we want to specify what is #stable for various combinations of platforms, we need a slightly different kind of versions. Dale calls these the symbolic versions.
>
> Cheers,
> Doru
>
>
> On 26 Nov 2010, at 18:06, Dale wrote:
>
>> Stef, Alexandre,
>>
>> I know I'm missing something, but I'm not sure what:) I don't think I
>> understand the confusing part...I know that I'm too close to the
>> soution, so I'll appreciate your patience while you educate me a
>> little bit more...
>>
>> Dale
>>
>> On Nov 26, 1:04 am, stephane ducasse<[hidden email]>
>> wrote:
>>> dale
>>>
>>> It would be really nice if you could take 10 min and extract a small but true example describing the problems
>>> like that we can paste it in the book chapter :)
>>> I'm sure other people will get confused.
>>> I think that the key point is to be able to specify that stable is relative to a platform version and that
>>> you do not have to write all the way such methods
>>>
>>>>>>> ConfigurationOfMondrian class>>   loadForPharo12
>>>>>>> (self project version: 'default') load
>>>
>>>>>>> ConfigurationOfMondrian loadForPharo111
>>>>>>> (self project version: '2.1.2') load
>>>
>>> this way you avoid ripple effect and get much more stable (non volatile) specs.
>>>
>>> Stef
>
> --
> www.tudorgirba.com
>
> "Beauty is where we see it."
>
>
>

> Yes...!
>
> On 11/26/2010 10:03 AM, Tudor Girba wrote:
>> Hi,
>>
>> Let me try an explanation.
>>
>> Metacello versions are used for versioning your configurations.
>>
>> However, these numbers do not have any meaning regarding the intended use and context. For example, when we want to specify what is #stable for various combinations of platforms, we need a slightly different kind of versions. Dale calls these the symbolic versions.
>>
>> Cheers,
>> Doru
>>
>>
>> On 26 Nov 2010, at 18:06, Dale wrote:
>>
>>> Stef, Alexandre,
>>>
>>> I know I'm missing something, but I'm not sure what:) I don't think I
>>> understand the confusing part...I know that I'm too close to the
>>> soution, so I'll appreciate your patience while you educate me a
>>> little bit more...
>>>
>>> Dale
>>>
>>> On Nov 26, 1:04 am, stephane ducasse<[hidden email]>
>>> wrote:
>>>> dale
>>>>
>>>> It would be really nice if you could take 10 min and extract a small but true example describing the problems
>>>> like that we can paste it in the book chapter :)
>>>> I'm sure other people will get confused.
>>>> I think that the key point is to be able to specify that stable is relative to a platform version and that
>>>> you do not have to write all the way such methods
>>>>
>>>>>>>> ConfigurationOfMondrian class>>   loadForPharo12
>>>>>>>> (self project version: 'default') load
>>>>
>>>>>>>> ConfigurationOfMondrian loadForPharo111
>>>>>>>> (self project version: '2.1.2') load
>>>>
>>>> this way you avoid ripple effect and get much more stable (non volatile) specs.
>>>>
>>>> Stef
>>
>> --
>> www.tudorgirba.com
>>
>> "Beauty is where we see it."
>>
>>
>>