Stupid question about #bleedingEdge.

Mariano,

There are no stupid questions or stupid users ... if you think you are stupid, then the documentation (or the underlying system) is to blame:)

If I understand what you are saying, you want load Marea two different ways:

 1) load the #bleedingEdge of Marea and the 'default' of Fuel
 2) load the #bleedingEdge of Marea and the #bleedingEdge of Fuel

You are also stating that you think that when loading the #bleedingEdge of Marea that the #bleeding edge of all of the dependent projects should be loaded as well ...

Finally, you are wondering what happens if

 1) you don't specify a version for the project reference in a
    baseline
 2) what is loaded when the #baseline version is loaded...

So I think we first need to understand what #bleedingEdge means then we'll get back to the relationship between Marea and Fuel...

What happens if you don't specify a version in the project reference?

ANSWER: The #baseline version is used.

What is loaded when the #baseline version is loaded?

ANSWER: That depends upon whether or not a #baseline version

has been specified in the target project.

If a #baseline version has been explicitly defined then that version is loaded. If no #baseline version is defined, then the following expression is evaluated (by default:):

 (ConfigurationOfXXX project map values
   select: [:version | version blessing == #baseline ])
   detectMax: [ :version | version ].

which is the latest baseline version....

At this point in time, it is worth noting the 'latest baseline version' result is skewed in projects for which named baseline versions like 'default', etc. are used. In cases where the 'latest baseline version' is unexpected, an explicit definition of #baseline should be specified.

Why isn't the #bleedingEdge version propogated in a load?

ANSWER: Because you would be even more unhappy:) Let's take OmniBrowser as an example. Noone who has a version of OmniBrowser that works in their image would want newer versions of OmniBrowser to be loaded into their image unless they explicitly did so themselves, yet there are several projects that depend upon OmniBrowser. Therefore, there must be a way to stop the "load latest madness" and I chose to be explicit up front.

Therefore the project that introduces OmniBrowser into the ecosystem can explicitly choose whether or not they want a version that works or the latest version of OmniBrowser loaded when the bleeding edge is loaded by specifying:

 - #stable in the bleeedingEdge baseline spec to avoid getting
   the latest OmniBrowser packages
 - #bleedingEdge to take your chances with the latest OmniBrowser
   packages
 - use an explict version, if that is what you need...

Finally to answer your original question, I think one solution would be to define a baseline version for Marea (say '1.0-bleedingEdge-baseline'that specifies the #bleedingEdge for Fuel and I would specify that version as the #bleedingEdge version for Marea.

I would then specify a second baseline version (say '1.0-baseline') that imports '1.0-bleedingEdge-baseline' that specifies the 'default' version for Fuel.

When you want the "propogated bleedingEdge" to be load, load #bleedingEdge. When you only want the latest packages for Marea loaded, load '1.0-baseline'.

Does this help?

Dale

----- Original Message -----
| From: "Mariano Martinez Peck" <[hidden email]>
| To: [hidden email]
| Sent: Monday, June 27, 2011 7:17:00 AM
| Subject: [Metacello] Stupid question about #bleedingEdge.
|
| Hi Dale. I feel stupid. I want to use #bleedingEdge, and I simply
| cannot.
| I have project Marea which has a project reference to Fuel.
| If I do
|
| (ConfigurationOfMarea project version: #bleedingEdge) load.
|
| I would expect to "propagate" the bleeding edge to its project
| dependencies, such as Fuel. However, it is NOT loading the very last
| version of Fuel but instead the last released version in
| ConfigurationOfFuel.
|
| The dependency in ConfigurationOfMarea is written this way:
|
|
| spec project: 'Fuel' with: [
| spec
| className: 'ConfigurationOfFuel';
| loads: #('default' );
| file: 'ConfigurationOfFuel';
| repository: ' http://www.squeaksource.com/Fuel ' ].
|
|
| I don't want to do #versionString such us:
|
| spec project: 'Fuel' with: [
| spec
| className: 'ConfigurationOfFuel';
| loads: #('default' );
| file: 'ConfigurationOfFuel';
| versionString: #bleedingEdge;
| repository: ' http://www.squeaksource.com/Fuel ' ].
|
| because SOMETIMES I want #bleedingEdge, in fact when I use
| #bleedingEdge method, but not always. I mean, I am not sure if I
| want #bleedingEdge as the default in case it was not specified.
|
| So...I guess that the "problem" is that the default version is the
| 'latest' instead of the very last version of every package. But I
| think we are mixing things:
|
| 1) One thing is the default version of a project when it is NOT
| specified. For example, I have a version in ConfigurationOfMArea
| which does not specify a version of Fuel. In such case, the defaul
| will load
| 2) What is loaded when used #bleedingEdge.
|
| What I mean is, when I use #bleedingEdge I want to download all the
| last versions of all my packges and my dependencies. I don't care
| what is the default (#versionString). Now I am forced to put
| #versionString: #bleedingEdge but I only want that when using such
| method. If I put #versionString and then I want to load a simple
| version of Marea that does not specify Fuel, I don't want to
| bleedingEdge, but instead the latest one.
|
| Maybe I am not being clear or I didn't understand anything about
| #bleedingEdge hehehe.
|
| Thanks dale
|
|
|
| --
| Mariano
| http://marianopeck.wordpress.com
|
|

 What happens if you don't specify a version in the project reference?

 ANSWER: The #latestVersion of the project is loaded. If no #latestVersion of the
 project exists, then the #bleedingEdge version is used.

 Note that it is now considered a "critical warning" to leave the #versionString
 specification empty. I would have preferred to make it an error, but there are
 too many existing configurations with empty #versionStrings.

 What is loaded when the #bleedingEdge version is loaded?

 ANSWER: That depends upon whether or not a #bleedingEdge version has been
 specified in the target project. If a #bleedingEdge version has been explicitly
 defined then that version is loaded. If no #bleedingEdge version is defined,

 then the following expression is evaluated (by default:

 (ConfigurationOfXXX project map values
   select: [:version | version blessing == #baseline ])
   detectMax: [ :version | version ].

 which is the latest baseline version....

 At this point in time, it is worth noting the 'latest baseline version'
 result is skewed in projects for which named baseline versions like
 'default', etc.   are used. In cases where the 'latest baseline version'
 is unexpected, an explicit definition of #baseline should be specified.

With regards to this comment about propogating the #bleedingEdge:

 But wouldn't those be the less cases?  I mean, wouldn't you want to always
 propagate the #bleedingEdge unless you specify NOT to do it? From my little
 point of view, most of the times we do want propagation. We faced the same
 problem with DBXTalk and Glorp last week. I think people understand by default
 that such thing is propagated.  Anyway....even more maybe it is too late to
 change it.

It is not about how often a choice is made and it is not about being too late. The lesson that I've learned with Metacello is that relying on default behavior is a bad thing ... it leads to lazy decisions being made and if/when the default behavior needs to change, it can be very difficult/wrong to change the default behavior. So with the introduction of symbolic versions I have deprecated the default loading behavior and am aiming towards explicit specifications with no defaults ...

I have reached the point where I know that it is _necessary_ to be able to specify the mcz version of the configuration that should be used to insulate a project from mistakes that may be made in later versions of the configuration ... which means that more explicit specifications are needed and the default behavior of loading the latest configuration version by default is also "wrong".

The important thing about Metacello is that it is an _explicit_ specification. Developers need to depend upon what happens when they load a configuration and developers in a project need to be able to control/specify the behavior of their project ....

With all of that said, tools can be created that perform the types of operations that you are looking for and that's the direction I suggest you head ... tools are the the vehicle for addressing "But wouldn't those be the less cases?" and  "I think people understand by default that such thing is propagated" .. the tools can wrap the Metacello specification and provide the end user with a smoother experience ... If you want to load the #bleedingEdge version of every project in the dependency chain, a tool can easily be written that allows you express that desire. Of course if such a tool were built, you'd have a way to say "don't load the #bleedingEdge of OmniBrowser":)

Dale


----- Original Message -----
| From: "Mariano Martinez Peck" <[hidden email]>
| To: [hidden email]

| Sent: Tuesday, June 28, 2011 1:10:38 AM
| Subject: Re: [Metacello] Stupid question about #bleedingEdge.
|
|
|
|
| On Mon, Jun 27, 2011 at 9:29 PM, Dale Henrichs < [hidden email]
| > wrote:
|
|
| Mariano,
|
|
|
| Thanks Dale for your detailed answer.
|
|
| There are no stupid questions or stupid users ... if you think you
| are stupid, then the documentation (or the underlying system) is to
| blame:)
|
| If I understand what you are saying, you want load Marea two
| different ways:
|
| 1) load the #bleedingEdge of Marea and the 'default' of Fuel
| 2) load the #bleedingEdge of Marea and the #bleedingEdge of Fuel
|
| You are also stating that you think that when loading the
| #bleedingEdge of Marea that the #bleeding edge of all of the
| dependent projects should be loaded as well ...
|
|
|
| More or less. I want two things:
|
| Case 1) Imagine that version Marea 4.5 uses baseline 4.5. The
| baseline does not use #versionString for Fuel and the version 4.5
| does not set any version for Fuel. So what happens? as far as I
| know, you take the latestVersion of Fuel in this case. Imagine that
| latestVersion of Fuel is 2.0.
|
| So, if I load Marea 4.5 and I want to get Fuel 2.0.
|
| Case 2) I want to load bleedingEdge of Marea meaning to load
| bleedingEdge of all its dependencies, included Fuel.
| In this case I want to load the last version of every single package
| of Marea and Fuel.
|
|
|
| Finally, you are wondering what happens if
|
| 1) you don't specify a version for the project reference in a
| baseline
| 2) what is loaded when the #baseline version is loaded...
|
| So I think we first need to understand what #bleedingEdge means then
| we'll get back to the relationship between Marea and Fuel...
|
|
|
| yes
|
|
| What happens if you don't specify a version in the project reference?
|
| ANSWER: The #baseline version is used.
|
|
|
| which one? Fuel has several baseline methods.
|
|
| What is loaded when the #baseline version is loaded?
|
| ANSWER: That depends upon whether or not a #baseline version
|
| I think I don't understand what do you mean by #baseline version.
| Normal/regular baselines?
|
|
| has been specified in the target project.
|
| how you can do this?
|
|
| If a #baseline version has been explicitly defined then that version
| is loaded. If no #baseline version is defined, then the following
| expression is evaluated (by default:):
|
| (ConfigurationOfXXX project map values
| select: [:version | version blessing == #baseline ])
| detectMax: [ :version | version ].
|
| which is the latest baseline version....
|
| At this point in time, it is worth noting the 'latest baseline
| version' result is skewed in projects for which named baseline
| versions like 'default', etc. are used. In cases where the 'latest
| baseline version' is unexpected, an explicit definition of #baseline
| should be specified.
|
|
|
| Wait...but this doesn't explain my results. I still don't understand.
| Imagine that Fuel does not depend on other project. If I load the
| 'latest baseline version' I will get all LAST monticello vesions of
| every package of Fuel since the baseline do not specify them. Right?
| However, when I do case 1), it is not loaded the 'latest baseline
| version' of Fuel (because that would mean last monticello versions).
| Instead, the 'latest version' of Fuel is loaded, which was 2.0.
|
|
|
|
| Why isn't the #bleedingEdge version propogated in a load?
|
| ANSWER: Because you would be even more unhappy:) Let's take
| OmniBrowser as an example. Noone who has a version of OmniBrowser
| that works in their image would want newer versions of OmniBrowser
| to be loaded into their image unless they explicitly did so
| themselves, yet there are several projects that depend upon
| OmniBrowser. Therefore, there must be a way to stop the "load latest
| madness" and I chose to be explicit up front.
|
| But wouldn't those be the less cases? I mean, wouldn't you want to
| always propagate the #bleedingEdge unless you specify NOT to do it?
| From my little point of view, most of the times we do want
| propagation. We faced the same problem with DBXTalk and Glorp last
| week. I think people understand by default that such thing is
| propagated. Anyway....even more maybe it is too late to change it.
|
|
| Therefore the project that introduces OmniBrowser into the ecosystem
| can explicitly choose whether or not they want a version that works
| or the latest version of OmniBrowser loaded when the bleeding edge
| is loaded by specifying:
|
| - #stable in the bleeedingEdge baseline spec to avoid getting
| the latest OmniBrowser packages
| - #bleedingEdge to take your chances with the latest OmniBrowser
| packages
| - use an explict version, if that is what you need...
|
| Finally to answer your original question, I think one solution would
| be to define a baseline version for Marea (say
| '1.0-bleedingEdge-baseline'that specifies the #bleedingEdge for Fuel
| and I would specify that version as the #bleedingEdge version for
| Marea.
|
| I would then specify a second baseline version (say '1.0-baseline')
| that imports '1.0-bleedingEdge-baseline' that specifies the
| 'default' version for Fuel.
|
|
|
| Ok, I think I understood. I will experiment a bit ;)
|
|
| When you want the "propogated bleedingEdge" to be load, load
| #bleedingEdge. When you only want the latest packages for Marea
| loaded, load '1.0-baseline'.
|
| Does this help?
|
|
| Yes, thanks Dale.
|
|
|
| Dale
|
|
|
|
| ----- Original Message -----
| | From: "Mariano Martinez Peck" < [hidden email] >
| | To: [hidden email]
| | Sent: Monday, June 27, 2011 7:17:00 AM
| | Subject: [Metacello] Stupid question about #bleedingEdge.
| |
| | Hi Dale. I feel stupid. I want to use #bleedingEdge, and I simply
| | cannot.
| | I have project Marea which has a project reference to Fuel.
| | If I do
| |
| | (ConfigurationOfMarea project version: #bleedingEdge) load.
| |
| | I would expect to "propagate" the bleeding edge to its project
| | dependencies, such as Fuel. However, it is NOT loading the very
| | last
| | version of Fuel but instead the last released version in
| | ConfigurationOfFuel.
| |
| | The dependency in ConfigurationOfMarea is written this way:
| |
| |
| | spec project: 'Fuel' with: [
| | spec
| | className: 'ConfigurationOfFuel';
| | loads: #('default' );
| | file: 'ConfigurationOfFuel';
| | repository: ' http://www.squeaksource.com/Fuel ' ].
| |
| |
| | I don't want to do #versionString such us:
| |
| | spec project: 'Fuel' with: [
| | spec
| | className: 'ConfigurationOfFuel';
| | loads: #('default' );
| | file: 'ConfigurationOfFuel';
| | versionString: #bleedingEdge;
| | repository: ' http://www.squeaksource.com/Fuel ' ].
| |
| | because SOMETIMES I want #bleedingEdge, in fact when I use
| | #bleedingEdge method, but not always. I mean, I am not sure if I
| | want #bleedingEdge as the default in case it was not specified.
| |
| | So...I guess that the "problem" is that the default version is the
| | 'latest' instead of the very last version of every package. But I
| | think we are mixing things:
| |
| | 1) One thing is the default version of a project when it is NOT
| | specified. For example, I have a version in ConfigurationOfMArea
| | which does not specify a version of Fuel. In such case, the defaul
| | will load
| | 2) What is loaded when used #bleedingEdge.
| |
| | What I mean is, when I use #bleedingEdge I want to download all the
| | last versions of all my packges and my dependencies. I don't care
| | what is the default (#versionString). Now I am forced to put
| | #versionString: #bleedingEdge but I only want that when using such
| | method. If I put #versionString and then I want to load a simple
| | version of Marea that does not specify Fuel, I don't want to
| | bleedingEdge, but instead the latest one.
| |
| | Maybe I am not being clear or I didn't understand anything about
| | #bleedingEdge hehehe.
| |
| | Thanks dale
| |
| |
| |
| | --
| | Mariano
| | http://marianopeck.wordpress.com
| |
| |
|
|
|
| --
| Mariano
| http://marianopeck.wordpress.com
|
|

Mariano,

You are correct to be looking for an alternative to just leaving the #versionString: blank ... we're trying to get away from hidden defaults.

The #stable symbolic version is pretty close to what you looking for. It defines the latest recommended version that should be used on a particular platform.

Since you are asking, I assume that you are looking for somethings a little bit different than #stable....

Did you know that you can define your own symbolic versions?

Let's say you want to define the symbolic version #latestVersion for ConfigurationOfExample.

You start by extending MetacelloBaseConfiguration with a #latestVersion method:

latestVersion

 <defaultSymbolicVersion: #latestVersion>

 ^self project latestVersion versionString

When you extend MetacelloBaseConfiguration you have access to the partially formed project (all literal versions are defined) so you can programmatically select a versionString. As I write this, I think it should be possible to accomplish this without having to extend MetacelloBaseConfiguration, but for the time being, it's the only way we have.

You can optionally add the following method to your configuration:

latestVersion

 <defaultSymbolicVersion: #latestVersion>

 ^'1.0'

When you do this, you don't have access to the project literal versions...

Finally you can then defined platform specific values with the following (familiar) method in your configuration:

latestVersion: spec

 <symbolicVersion: #stable>

 spec for: #'common' version: '1.0'.

Does this get close to what you are looking for?

Dale




----- Original Message -----
| From: "Mariano Martinez Peck" <[hidden email]>
| To: [hidden email]

| Sent: Friday, October 21, 2011 2:34:16 AM
| Subject: Re: [Metacello] Stupid question about #bleedingEdge.
|
|
|
|
|
|
|
|
| What happens if you don't specify a version in the project reference?
|
| ANSWER: The #latestVersion of the project is loaded. If no
| #latestVersion of the
| project exists, then the #bleedingEdge version is used.
|
| Note that it is now considered a "critical warning" to leave the
| #versionString
| specification empty. I would have preferred to make it an error, but
| there are
| too many existing configurations with empty #versionStrings.
|
|
|
| Hi Dale. I come again with this old thread because there is something
| I don't understand. I have another scenario (not the one mentioned
| here about Marea and Fuel) here.
| So..if I don't specify a version in the project reference,
| #latestVersion is used. That is exactly what I want in this
| scenario.
| Then you say I should not let #versionString empty.... Hence, I tried
| to do
|
| versionString: #'latestVersion';
|
| or
|
| versionString: #latestVersion;
|
| But it didn't work. So, I don't know how to explicitly say to
| Metacello that I want #latestVersion as the project reference. I
| wouldn't like to have to implement anything in the project
| reference, since #latestVersion does not depend on in (it is always
| the last version which is not #development or #broken, or..).
|
| Of course, if I remove the versionString specification, it works as I
| want. But I would like to make it clearer.
|
| How can I do this Dale?
|
| Thanks!
|
|
| What is loaded when the #bleedingEdge version is loaded?
|
| ANSWER: That depends upon whether or not a #bleedingEdge version has
| been
| specified in the target project. If a #bleedingEdge version has been
| explicitly
| defined then that version is loaded. If no #bleedingEdge version is
| defined,
|
| then the following expression is evaluated (by default:
|
|
| (ConfigurationOfXXX project map values
| select: [:version | version blessing == #baseline ])
| detectMax: [ :version | version ].
|
| which is the latest baseline version....
|
| At this point in time, it is worth noting the 'latest baseline
| version'
| result is skewed in projects for which named baseline versions like
| 'default', etc. are used. In cases where the 'latest baseline
| version'
| is unexpected, an explicit definition of #baseline should be
| specified.
|
| With regards to this comment about propogating the #bleedingEdge:
|
|
| But wouldn't those be the less cases? I mean, wouldn't you want to
| always
| propagate the #bleedingEdge unless you specify NOT to do it? From my
| little
| point of view, most of the times we do want propagation. We faced the
| same
| problem with DBXTalk and Glorp last week. I think people understand
| by default
| that such thing is propagated. Anyway....even more maybe it is too
| late to
| change it.
|
| It is not about how often a choice is made and it is not about being
| too late. The lesson that I've learned with Metacello is that
| relying on default behavior is a bad thing ... it leads to lazy
| decisions being made and if/when the default behavior needs to
| change, it can be very difficult/wrong to change the default
| behavior. So with the introduction of symbolic versions I have
| deprecated the default loading behavior and am aiming towards
| explicit specifications with no defaults ...
|
| I have reached the point where I know that it is _necessary_ to be
| able to specify the mcz version of the configuration that should be
| used to insulate a project from mistakes that may be made in later
| versions of the configuration ... which means that more explicit
| specifications are needed and the default behavior of loading the
| latest configuration version by default is also "wrong".
|
| The important thing about Metacello is that it is an _explicit_
| specification. Developers need to depend upon what happens when they
| load a configuration and developers in a project need to be able to
| control/specify the behavior of their project ....
|
| With all of that said, tools can be created that perform the types of
| operations that you are looking for and that's the direction I
| suggest you head ... tools are the the vehicle for addressing "But
| wouldn't those be the less cases?" and "I think people understand by
| default that such thing is propagated" .. the tools can wrap the
| Metacello specification and provide the end user with a smoother
| experience ... If you want to load the #bleedingEdge version of
| every project in the dependency chain, a tool can easily be written
| that allows you express that desire. Of course if such a tool were
| built, you'd have a way to say "don't load the #bleedingEdge of
| OmniBrowser":)
|
|
| Dale
|
|
| ----- Original Message -----
| | From: "Mariano Martinez Peck" < [hidden email] >
| | To: [hidden email]
|
|
|
| | Sent: Tuesday, June 28, 2011 1:10:38 AM
| | Subject: Re: [Metacello] Stupid question about #bleedingEdge.
| |
| |
| |
| |
| | On Mon, Jun 27, 2011 at 9:29 PM, Dale Henrichs <
| | [hidden email]
| | > wrote:
| |
| |
| | Mariano,
| |
| |
| |
| | Thanks Dale for your detailed answer.
| |
| |
| | There are no stupid questions or stupid users ... if you think you
| | are stupid, then the documentation (or the underlying system) is to
| | blame:)
| |
| | If I understand what you are saying, you want load Marea two
| | different ways:
| |
| | 1) load the #bleedingEdge of Marea and the 'default' of Fuel
| | 2) load the #bleedingEdge of Marea and the #bleedingEdge of Fuel
| |
| | You are also stating that you think that when loading the
| | #bleedingEdge of Marea that the #bleeding edge of all of the
| | dependent projects should be loaded as well ...
| |
| |
| |
| | More or less. I want two things:
| |
| | Case 1) Imagine that version Marea 4.5 uses baseline 4.5. The
| | baseline does not use #versionString for Fuel and the version 4.5
| | does not set any version for Fuel. So what happens? as far as I
| | know, you take the latestVersion of Fuel in this case. Imagine that
| | latestVersion of Fuel is 2.0.
| |
| | So, if I load Marea 4.5 and I want to get Fuel 2.0.
| |
| | Case 2) I want to load bleedingEdge of Marea meaning to load
| | bleedingEdge of all its dependencies, included Fuel.
| | In this case I want to load the last version of every single
| | package
| | of Marea and Fuel.
| |
| |
| |
| | Finally, you are wondering what happens if
| |
| | 1) you don't specify a version for the project reference in a
| | baseline
| | 2) what is loaded when the #baseline version is loaded...
| |
| | So I think we first need to understand what #bleedingEdge means
| | then
| | we'll get back to the relationship between Marea and Fuel...
| |
| |
| |
| | yes
| |
| |
| | What happens if you don't specify a version in the project
| | reference?
| |
| | ANSWER: The #baseline version is used.
| |
| |
| |
| | which one? Fuel has several baseline methods.
| |
| |
| | What is loaded when the #baseline version is loaded?
| |
| | ANSWER: That depends upon whether or not a #baseline version
| |
| | I think I don't understand what do you mean by #baseline version.
| | Normal/regular baselines?
| |
| |
| | has been specified in the target project.
| |
| | how you can do this?
| |
| |
| | If a #baseline version has been explicitly defined then that
| | version
| | is loaded. If no #baseline version is defined, then the following
| | expression is evaluated (by default:):
| |
| | (ConfigurationOfXXX project map values
| | select: [:version | version blessing == #baseline ])
| | detectMax: [ :version | version ].
| |
| | which is the latest baseline version....
| |
| | At this point in time, it is worth noting the 'latest baseline
| | version' result is skewed in projects for which named baseline
| | versions like 'default', etc. are used. In cases where the 'latest
| | baseline version' is unexpected, an explicit definition of
| | #baseline
| | should be specified.
| |
| |
| |
| | Wait...but this doesn't explain my results. I still don't
| | understand.
| | Imagine that Fuel does not depend on other project. If I load the
| | 'latest baseline version' I will get all LAST monticello vesions of
| | every package of Fuel since the baseline do not specify them.
| | Right?
| | However, when I do case 1), it is not loaded the 'latest baseline
| | version' of Fuel (because that would mean last monticello
| | versions).
| | Instead, the 'latest version' of Fuel is loaded, which was 2.0.
| |
| |
| |
| |
| | Why isn't the #bleedingEdge version propogated in a load?
| |
| | ANSWER: Because you would be even more unhappy:) Let's take
| | OmniBrowser as an example. Noone who has a version of OmniBrowser
| | that works in their image would want newer versions of OmniBrowser
| | to be loaded into their image unless they explicitly did so
| | themselves, yet there are several projects that depend upon
| | OmniBrowser. Therefore, there must be a way to stop the "load
| | latest
| | madness" and I chose to be explicit up front.
| |
| | But wouldn't those be the less cases? I mean, wouldn't you want to
| | always propagate the #bleedingEdge unless you specify NOT to do it?
| | From my little point of view, most of the times we do want
| | propagation. We faced the same problem with DBXTalk and Glorp last
| | week. I think people understand by default that such thing is
| | propagated. Anyway....even more maybe it is too late to change it.
| |
| |
| | Therefore the project that introduces OmniBrowser into the
| | ecosystem
| | can explicitly choose whether or not they want a version that works
| | or the latest version of OmniBrowser loaded when the bleeding edge
| | is loaded by specifying:
| |
| | - #stable in the bleeedingEdge baseline spec to avoid getting
| | the latest OmniBrowser packages
| | - #bleedingEdge to take your chances with the latest OmniBrowser
| | packages
| | - use an explict version, if that is what you need...
| |
| | Finally to answer your original question, I think one solution
| | would
| | be to define a baseline version for Marea (say
| | '1.0-bleedingEdge-baseline'that specifies the #bleedingEdge for
| | Fuel
| | and I would specify that version as the #bleedingEdge version for
| | Marea.
| |
| | I would then specify a second baseline version (say '1.0-baseline')
| | that imports '1.0-bleedingEdge-baseline' that specifies the
| | 'default' version for Fuel.
| |
| |
| |
| | Ok, I think I understood. I will experiment a bit ;)
| |
| |
| | When you want the "propogated bleedingEdge" to be load, load
| | #bleedingEdge. When you only want the latest packages for Marea
| | loaded, load '1.0-baseline'.
| |
| | Does this help?
| |
| |
| | Yes, thanks Dale.
| |
| |
| |
| | Dale
| |
| |
| |
| |
| | ----- Original Message -----
| | | From: "Mariano Martinez Peck" < [hidden email] >
| | | To: [hidden email]
| | | Sent: Monday, June 27, 2011 7:17:00 AM
| | | Subject: [Metacello] Stupid question about #bleedingEdge.
| | |
| | | Hi Dale. I feel stupid. I want to use #bleedingEdge, and I simply
| | | cannot.
| | | I have project Marea which has a project reference to Fuel.
| | | If I do
| | |
| | | (ConfigurationOfMarea project version: #bleedingEdge) load.
| | |
| | | I would expect to "propagate" the bleeding edge to its project
| | | dependencies, such as Fuel. However, it is NOT loading the very
| | | last
| | | version of Fuel but instead the last released version in
| | | ConfigurationOfFuel.
| | |
| | | The dependency in ConfigurationOfMarea is written this way:
| | |
| | |
| | | spec project: 'Fuel' with: [
| | | spec
| | | className: 'ConfigurationOfFuel';
| | | loads: #('default' );
| | | file: 'ConfigurationOfFuel';
| | | repository: ' http://www.squeaksource.com/Fuel ' ].
| | |
| | |
| | | I don't want to do #versionString such us:
| | |
| | | spec project: 'Fuel' with: [
| | | spec
| | | className: 'ConfigurationOfFuel';
| | | loads: #('default' );
| | | file: 'ConfigurationOfFuel';
| | | versionString: #bleedingEdge;
| | | repository: ' http://www.squeaksource.com/Fuel ' ].
| | |
| | | because SOMETIMES I want #bleedingEdge, in fact when I use
| | | #bleedingEdge method, but not always. I mean, I am not sure if I
| | | want #bleedingEdge as the default in case it was not specified.
| | |
| | | So...I guess that the "problem" is that the default version is
| | | the
| | | 'latest' instead of the very last version of every package. But I
| | | think we are mixing things:
| | |
| | | 1) One thing is the default version of a project when it is NOT
| | | specified. For example, I have a version in ConfigurationOfMArea
| | | which does not specify a version of Fuel. In such case, the
| | | defaul
| | | will load
| | | 2) What is loaded when used #bleedingEdge.
| | |
| | | What I mean is, when I use #bleedingEdge I want to download all
| | | the
| | | last versions of all my packges and my dependencies. I don't care
| | | what is the default (#versionString). Now I am forced to put
| | | #versionString: #bleedingEdge but I only want that when using
| | | such
| | | method. If I put #versionString and then I want to load a simple
| | | version of Marea that does not specify Fuel, I don't want to
| | | bleedingEdge, but instead the latest one.
| | |
| | | Maybe I am not being clear or I didn't understand anything about
| | | #bleedingEdge hehehe.
| | |
| | | Thanks dale
| | |
| | |
| | |
| | | --
| | | Mariano
| | | http://marianopeck.wordpress.com
| | |
| | |
| |
| |
| |
| | --
| | Mariano
| | http://marianopeck.wordpress.com
| |
| |
|
|
|
| --
| Mariano
| http://marianopeck.wordpress.com
|
|

On Fri, Oct 21, 2011 at 6:34 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

You are correct to be looking for an alternative to just leaving the #versionString: blank ... we're trying to get away from hidden defaults.

The #stable symbolic version is pretty close to what you looking for. It defines the latest recommended version that should be used on a particular platform.

There is one big difference: #stable should be defined in the conf I refer... which is not always the case. And sometimes, since I may refer projects I don't really know that much, I don't feel brave enough to write #stable in such projects. In contrast, when I do NOT set a versionString, it is automatically choosen what I want WITHOUT touching the referenced project.
So, I would like to do the same, but explicitly setting that in #versionString.
 

Since you are asking, I assume that you are looking for somethings a little bit different than #stable....

Did you know that you can define your own symbolic versions?

No, that's cool :)
 

Let's say you want to define the symbolic version #latestVersion for ConfigurationOfExample.

You start by extending MetacelloBaseConfiguration with a #latestVersion method:

latestVersion

 <defaultSymbolicVersion: #latestVersion>

 ^self project latestVersion versionString

When you extend MetacelloBaseConfiguration you have access to the partially formed project (all literal versions are defined) so you can programmatically select a versionString. As I write this, I think it should be possible to accomplish this without having to extend MetacelloBaseConfiguration, but for the time being, it's the only way we have.

You can optionally add the following method to your configuration:

latestVersion

 <defaultSymbolicVersion: #latestVersion>

 ^'1.0'

When you do this, you don't have access to the project literal versions...

Finally you can then defined platform specific values with the following (familiar) method in your configuration:

latestVersion: spec

 <symbolicVersion: #stable>

 spec for: #'common' version: '1.0'.

Does this get close to what you are looking for?

Wow. All that is awesome and I was not aware I could do that. But it's not exactly what I need. Maybe I am being too puristic. But what I want is to be able to explicitly set something in #versionString that does exactly what happens when I let it empty, but without changing nor adding anything to the referenced project.

But as said, it is not something really mandatory, since I can live with letting #versionString empty.

Thanks Dale!


 

Dale




----- Original Message -----
| From: "Mariano Martinez Peck" <[hidden email]>
| To: [hidden email]

| Sent: Friday, October 21, 2011 2:34:16 AM
| Subject: Re: [Metacello] Stupid question about #bleedingEdge.
|
|
|
|
|
|
|
|
| What happens if you don't specify a version in the project reference?
|
| ANSWER: The #latestVersion of the project is loaded. If no
| #latestVersion of the
| project exists, then the #bleedingEdge version is used.
|
| Note that it is now considered a "critical warning" to leave the
| #versionString
| specification empty. I would have preferred to make it an error, but
| there are
| too many existing configurations with empty #versionStrings.
|
|
|
| Hi Dale. I come again with this old thread because there is something
| I don't understand. I have another scenario (not the one mentioned
| here about Marea and Fuel) here.
| So..if I don't specify a version in the project reference,
| #latestVersion is used. That is exactly what I want in this
| scenario.
| Then you say I should not let #versionString empty.... Hence, I tried
| to do
|
| versionString: #'latestVersion';
|
| or
|
| versionString: #latestVersion;
|
| But it didn't work. So, I don't know how to explicitly say to
| Metacello that I want #latestVersion as the project reference. I
| wouldn't like to have to implement anything in the project
| reference, since #latestVersion does not depend on in (it is always
| the last version which is not #development or #broken, or..).
|
| Of course, if I remove the versionString specification, it works as I
| want. But I would like to make it clearer.
|
| How can I do this Dale?
|
| Thanks!
|
|
| What is loaded when the #bleedingEdge version is loaded?
|
| ANSWER: That depends upon whether or not a #bleedingEdge version has
| been
| specified in the target project. If a #bleedingEdge version has been
| explicitly
| defined then that version is loaded. If no #bleedingEdge version is
| defined,
|
| then the following expression is evaluated (by default:
|
|
| (ConfigurationOfXXX project map values
| select: [:version | version blessing == #baseline ])
| detectMax: [ :version | version ].
|
| which is the latest baseline version....
|
| At this point in time, it is worth noting the 'latest baseline
| version'
| result is skewed in projects for which named baseline versions like
| 'default', etc. are used. In cases where the 'latest baseline
| version'
| is unexpected, an explicit definition of #baseline should be
| specified.
|
| With regards to this comment about propogating the #bleedingEdge:
|
|
| But wouldn't those be the less cases? I mean, wouldn't you want to
| always
| propagate the #bleedingEdge unless you specify NOT to do it? From my
| little
| point of view, most of the times we do want propagation. We faced the
| same
| problem with DBXTalk and Glorp last week. I think people understand
| by default
| that such thing is propagated. Anyway....even more maybe it is too
| late to
| change it.
|
| It is not about how often a choice is made and it is not about being
| too late. The lesson that I've learned with Metacello is that
| relying on default behavior is a bad thing ... it leads to lazy
| decisions being made and if/when the default behavior needs to
| change, it can be very difficult/wrong to change the default
| behavior. So with the introduction of symbolic versions I have
| deprecated the default loading behavior and am aiming towards
| explicit specifications with no defaults ...
|
| I have reached the point where I know that it is _necessary_ to be
| able to specify the mcz version of the configuration that should be
| used to insulate a project from mistakes that may be made in later
| versions of the configuration ... which means that more explicit
| specifications are needed and the default behavior of loading the
| latest configuration version by default is also "wrong".
|
| The important thing about Metacello is that it is an _explicit_
| specification. Developers need to depend upon what happens when they
| load a configuration and developers in a project need to be able to
| control/specify the behavior of their project ....
|
| With all of that said, tools can be created that perform the types of
| operations that you are looking for and that's the direction I
| suggest you head ... tools are the the vehicle for addressing "But
| wouldn't those be the less cases?" and "I think people understand by
| default that such thing is propagated" .. the tools can wrap the
| Metacello specification and provide the end user with a smoother
| experience ... If you want to load the #bleedingEdge version of
| every project in the dependency chain, a tool can easily be written
| that allows you express that desire. Of course if such a tool were
| built, you'd have a way to say "don't load the #bleedingEdge of
| OmniBrowser":)
|
|
| Dale
|
|
| ----- Original Message -----
| | From: "Mariano Martinez Peck" < [hidden email] >
| | To: [hidden email]
|
|
|
| | Sent: Tuesday, June 28, 2011 1:10:38 AM
| | Subject: Re: [Metacello] Stupid question about #bleedingEdge.
| |
| |
| |
| |
| | On Mon, Jun 27, 2011 at 9:29 PM, Dale Henrichs <
| | [hidden email]
| | > wrote:
| |
| |
| | Mariano,
| |
| |
| |
| | Thanks Dale for your detailed answer.
| |
| |
| | There are no stupid questions or stupid users ... if you think you
| | are stupid, then the documentation (or the underlying system) is to
| | blame:)
| |
| | If I understand what you are saying, you want load Marea two
| | different ways:
| |
| | 1) load the #bleedingEdge of Marea and the 'default' of Fuel
| | 2) load the #bleedingEdge of Marea and the #bleedingEdge of Fuel
| |
| | You are also stating that you think that when loading the
| | #bleedingEdge of Marea that the #bleeding edge of all of the
| | dependent projects should be loaded as well ...
| |
| |
| |
| | More or less. I want two things:
| |
| | Case 1) Imagine that version Marea 4.5 uses baseline 4.5. The
| | baseline does not use #versionString for Fuel and the version 4.5
| | does not set any version for Fuel. So what happens? as far as I
| | know, you take the latestVersion of Fuel in this case. Imagine that
| | latestVersion of Fuel is 2.0.
| |
| | So, if I load Marea 4.5 and I want to get Fuel 2.0.
| |
| | Case 2) I want to load bleedingEdge of Marea meaning to load
| | bleedingEdge of all its dependencies, included Fuel.
| | In this case I want to load the last version of every single
| | package
| | of Marea and Fuel.
| |
| |
| |
| | Finally, you are wondering what happens if
| |
| | 1) you don't specify a version for the project reference in a
| | baseline
| | 2) what is loaded when the #baseline version is loaded...
| |
| | So I think we first need to understand what #bleedingEdge means
| | then
| | we'll get back to the relationship between Marea and Fuel...
| |
| |
| |
| | yes
| |
| |
| | What happens if you don't specify a version in the project
| | reference?
| |
| | ANSWER: The #baseline version is used.
| |
| |
| |
| | which one? Fuel has several baseline methods.
| |
| |
| | What is loaded when the #baseline version is loaded?
| |
| | ANSWER: That depends upon whether or not a #baseline version
| |
| | I think I don't understand what do you mean by #baseline version.
| | Normal/regular baselines?
| |
| |
| | has been specified in the target project.
| |
| | how you can do this?
| |
| |
| | If a #baseline version has been explicitly defined then that
| | version
| | is loaded. If no #baseline version is defined, then the following
| | expression is evaluated (by default:):
| |
| | (ConfigurationOfXXX project map values
| | select: [:version | version blessing == #baseline ])
| | detectMax: [ :version | version ].
| |
| | which is the latest baseline version....
| |
| | At this point in time, it is worth noting the 'latest baseline
| | version' result is skewed in projects for which named baseline
| | versions like 'default', etc. are used. In cases where the 'latest
| | baseline version' is unexpected, an explicit definition of
| | #baseline
| | should be specified.
| |
| |
| |
| | Wait...but this doesn't explain my results. I still don't
| | understand.
| | Imagine that Fuel does not depend on other project. If I load the
| | 'latest baseline version' I will get all LAST monticello vesions of
| | every package of Fuel since the baseline do not specify them.
| | Right?
| | However, when I do case 1), it is not loaded the 'latest baseline
| | version' of Fuel (because that would mean last monticello
| | versions).
| | Instead, the 'latest version' of Fuel is loaded, which was 2.0.
| |
| |
| |
| |
| | Why isn't the #bleedingEdge version propogated in a load?
| |
| | ANSWER: Because you would be even more unhappy:) Let's take
| | OmniBrowser as an example. Noone who has a version of OmniBrowser
| | that works in their image would want newer versions of OmniBrowser
| | to be loaded into their image unless they explicitly did so
| | themselves, yet there are several projects that depend upon
| | OmniBrowser. Therefore, there must be a way to stop the "load
| | latest
| | madness" and I chose to be explicit up front.
| |
| | But wouldn't those be the less cases? I mean, wouldn't you want to
| | always propagate the #bleedingEdge unless you specify NOT to do it?
| | From my little point of view, most of the times we do want
| | propagation. We faced the same problem with DBXTalk and Glorp last
| | week. I think people understand by default that such thing is
| | propagated. Anyway....even more maybe it is too late to change it.
| |
| |
| | Therefore the project that introduces OmniBrowser into the
| | ecosystem
| | can explicitly choose whether or not they want a version that works
| | or the latest version of OmniBrowser loaded when the bleeding edge
| | is loaded by specifying:
| |
| | - #stable in the bleeedingEdge baseline spec to avoid getting
| | the latest OmniBrowser packages
| | - #bleedingEdge to take your chances with the latest OmniBrowser
| | packages
| | - use an explict version, if that is what you need...
| |
| | Finally to answer your original question, I think one solution
| | would
| | be to define a baseline version for Marea (say
| | '1.0-bleedingEdge-baseline'that specifies the #bleedingEdge for
| | Fuel
| | and I would specify that version as the #bleedingEdge version for
| | Marea.
| |
| | I would then specify a second baseline version (say '1.0-baseline')
| | that imports '1.0-bleedingEdge-baseline' that specifies the
| | 'default' version for Fuel.
| |
| |
| |
| | Ok, I think I understood. I will experiment a bit ;)
| |
| |
| | When you want the "propogated bleedingEdge" to be load, load
| | #bleedingEdge. When you only want the latest packages for Marea
| | loaded, load '1.0-baseline'.
| |
| | Does this help?
| |
| |
| | Yes, thanks Dale.
| |
| |
| |
| | Dale
| |
| |
| |
| |
| | ----- Original Message -----
| | | From: "Mariano Martinez Peck" < [hidden email] >
| | | To: [hidden email]
| | | Sent: Monday, June 27, 2011 7:17:00 AM
| | | Subject: [Metacello] Stupid question about #bleedingEdge.
| | |
| | | Hi Dale. I feel stupid. I want to use #bleedingEdge, and I simply
| | | cannot.
| | | I have project Marea which has a project reference to Fuel.
| | | If I do
| | |
| | | (ConfigurationOfMarea project version: #bleedingEdge) load.
| | |
| | | I would expect to "propagate" the bleeding edge to its project
| | | dependencies, such as Fuel. However, it is NOT loading the very
| | | last
| | | version of Fuel but instead the last released version in
| | | ConfigurationOfFuel.
| | |
| | | The dependency in ConfigurationOfMarea is written this way:
| | |
| | |
| | | spec project: 'Fuel' with: [
| | | spec
| | | className: 'ConfigurationOfFuel';
| | | loads: #('default' );
| | | file: 'ConfigurationOfFuel';
| | | repository: ' http://www.squeaksource.com/Fuel ' ].
| | |
| | |
| | | I don't want to do #versionString such us:
| | |
| | | spec project: 'Fuel' with: [
| | | spec
| | | className: 'ConfigurationOfFuel';
| | | loads: #('default' );
| | | file: 'ConfigurationOfFuel';
| | | versionString: #bleedingEdge;
| | | repository: ' http://www.squeaksource.com/Fuel ' ].
| | |
| | | because SOMETIMES I want #bleedingEdge, in fact when I use
| | | #bleedingEdge method, but not always. I mean, I am not sure if I
| | | want #bleedingEdge as the default in case it was not specified.
| | |
| | | So...I guess that the "problem" is that the default version is
| | | the
| | | 'latest' instead of the very last version of every package. But I
| | | think we are mixing things:
| | |
| | | 1) One thing is the default version of a project when it is NOT
| | | specified. For example, I have a version in ConfigurationOfMArea
| | | which does not specify a version of Fuel. In such case, the
| | | defaul
| | | will load
| | | 2) What is loaded when used #bleedingEdge.
| | |
| | | What I mean is, when I use #bleedingEdge I want to download all
| | | the
| | | last versions of all my packges and my dependencies. I don't care
| | | what is the default (#versionString). Now I am forced to put
| | | #versionString: #bleedingEdge but I only want that when using
| | | such
| | | method. If I put #versionString and then I want to load a simple
| | | version of Marea that does not specify Fuel, I don't want to
| | | bleedingEdge, but instead the latest one.
| | |
| | | Maybe I am not being clear or I didn't understand anything about
| | | #bleedingEdge hehehe.
| | |
| | | Thanks dale
| | |
| | |
| | |
| | | --
| | | Mariano
| | | http://marianopeck.wordpress.com
| | |
| | |
| |
| |
| |
| | --
| | Mariano
| | http://marianopeck.wordpress.com
| |
| |
|
|
|
| --
| Mariano
| http://marianopeck.wordpress.com
|
|

--
Mariano
http://marianopeck.wordpress.com