Something is broken with #record

|
| Very few people (if anyone) has noticed that Metacello has this rule,
|
| me!!! ;)

Yes and I'm glad it was you:)

|
|
| because in most cases, if you were given the choice you would say ...
| yes please upgrade my project version and no please don't downgrade
| my project version ... If you really want an older version loaded
| explicitly loading the old version via ConfigurationOF would do as
| you ask ...
|
|
|
| yes, but then I have to be careful that no other guy will bring a new
| version because otherwise it will be updated.

In 1.0-beta.32, I have changed the sematics of #stable a bit ... I haven't released this yet because I need to consider the consequences...but the feature is that the #stable version is treated specially (again only for project refs):

 - if the project is not already loaded, load the version specified by #stable
 - if the project is present do not upgrade or downgrade ...

#stable is supposed to be used when there is a loose coupling...so a loose coupling should not cause an upgrade ... I think that in the latter stages of the pharo 1.3 development cycle a certain class of bugs involving OB were caused by the "automatic upgrade of #stable projects"...Again if you explicitly load #stable the upgrade will be performed ...

I mention this because I think that you are referring to exactly that problem ...

|
|
| The reason for doing this has to do with the fact that a project like
| Magritte specific version 3.0.1 of Seaside ... when Seaside3.0.2
| came out, I didn't want folks who hasd already explicitly upgraded
| to Seaside3.0.2 have Seaside downgraded to version 3.0.1 when
| Magritte was loaded ... that would have wreaked havoc all over the
| place ...
|
|
| ok, I see.
|
|
|
| Dale
|
|
|
| --
| Mariano
| http://marianopeck.wordpress.com
|
|

|
| Ok, I now understand all that. Still, I don't understand why in my
| case someone could be loading Nautilus apart from me? I
| mean...who/why is loading version 4.0?
| I cannot do the #record: because of the other bug (I guess that
| loading the latest baseline of Metacello would have the problem of
| #record fixed)

This is the problem with the difference between:

 '4.04' -> 4-04

relative to:

 '4.0. -> 4.0

I encourage you to play with the following expressions:

 | v404 v40 v44 v40beta |
 v404 := '4.04' asMetacelloVersionNumber.
 v40beta := '4.0-beta' asMetacelloVersionNumber.
 v40 := '4.0' asMetacelloVersionNumber.
 v44 := '4.4' asMetacelloVersionNumber.
 {v404.  v40beta. v40. v44} sorted

and look at the documentation on Metacello version formats[1].

You should see how the various strings are parsed into version numbers and then understand how Metacello calculates the latest version and determines which version is later than another.

I think you will find that if the version is named '4.4' instead of '4.04' that everything works as you expect ...

|

| Thanks
|
|
|
|
| I mention this because I think that you are referring to exactly that
| problem ...
|
|
| |
| |
| | The reason for doing this has to do with the fact that a project
| | like
| | Magritte specific version 3.0.1 of Seaside ... when Seaside3.0.2
| | came out, I didn't want folks who hasd already explicitly upgraded
| | to Seaside3.0.2 have Seaside downgraded to version 3.0.1 when
| | Magritte was loaded ... that would have wreaked havoc all over the
| | place ...
| |
| |
| | ok, I see.
| |
| |
| |
| | Dale
| |
| |
| |
| | --
| | Mariano
| | http://marianopeck.wordpress.com
| |
| |
|
|
|
| --
| Mariano
| http://marianopeck.wordpress.com
|
|

----- Original Message -----
| From: "Frank Shearar" <[hidden email]>
| To: [hidden email]

| Sent: Wednesday, February 29, 2012 10:06:49 AM
| Subject: Re: [Metacello] Something is broken with #record
|
| On 29 February 2012 17:32, Dale Henrichs <[hidden email]> wrote:
| >
| >
| > ----- Original Message -----
| > | From: "Mariano Martinez Peck" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Wednesday, February 29, 2012 12:57:01 AM
| > | Subject: Re: [Metacello] Something is broken with #record
| > |
| > |
| > |
| > |
| > |
| > |
| > |
| > | |
| > | | Ok, I now understand all that. Still, I don't understand why in
| > | | my
| > | | case someone could be loading Nautilus apart from me? I
| > | | mean...who/why is loading version 4.0?
| > | | I cannot do the #record: because of the other bug (I guess that
| > | | loading the latest baseline of Metacello would have the problem
| > | | of
| > | | #record fixed)
| > |
| > | This is the problem with the difference between:
| > |
| > | '4.04' -> 4-04
| > |
| > | relative to:
| > |
| > | '4.0. -> 4.0
| > |
| > | I encourage you to play with the following expressions:
| > |
| > | | v404 v40 v44 v40beta |
| > | v404 := '4.04' asMetacelloVersionNumber.
| > | v40beta := '4.0-beta' asMetacelloVersionNumber.
| > | v40 := '4.0' asMetacelloVersionNumber.
| > | v44 := '4.4' asMetacelloVersionNumber.
| > | {v404. v40beta. v40. v44} sorted
| > |
| > | and look at the documentation on Metacello version formats[1].
| > |
| > | You should see how the various strings are parsed into version
| > | numbers and then understand how Metacello calculates the latest
| > | version and determines which version is later than another.
| > |
| > | I think you will find that if the version is named '4.4' instead
| > | of
| > | '4.04' that everything works as you expect ...
| > |
| > |
| > |
| > | Hi Dale. This looks like the type of discussion that even if we
| > | both
| > | have the best intentions, we won't get to anything. So I will do
| > | my
| > | last shoot if and I don't get it, I give up.
| > |
| > | 1) I DO understand the problem tha '4.04' get sorted before
| > | '4.0'. I
| > | do understand all the previous explanations.
| > | 2) I DO know that if I put '4.4' instead of '4.04' it will all
| > | work
| > | fine. But still, there is something I don't understand and I
| > | would
| > | just to know what it is.
| > |
| > | Several times you said things like "Metacello calculates the
| > | latest
| > | version and determines which version is later than another". But
| > | you
| > | never answered my question: WHY in MY particlar case, Metacello
| > | needs to calculate the latest version? In addition, if you say
| > | "determines which version is later than another" then it means
| > | there
| > | are at least to version. In my case NO-ONE apart from
| > | ConfigurationOfMariano has a reference to
| > | ConfigurationOfNautilus.
| > | So, WHY in my case there is a case where it looks like two
| > | versions
| > | of Nautilus are there and hence you need to sort and hence the
| > | problem.
| > |
| > | To continue with what I don't understand. If you take the
| > | ConfigurationOfMariano I told you and evaluate:
| > |
| > | ((Smalltalk at: #ConfigurationOfMariano) project version:
| > | #bleedingEdge) load: 'BaseImage'
| > |
| > | That WORKS without problem. Everything is perfect. That even
| > | loads
| > | Nautilus. So I guess here there is no sorting and Metacello
| > | doesn't
| > | need to know which is the latest version of Nautilus etc etc etc
| > |
| > | However, if I do execute:
| > |
| > | ((Smalltalk at: #ConfigurationOfMariano) project version:
| > | #bleedingEdge) load: 'MareaImage'
| > |
| > | I have the mentioned problem. What is the difference? THE only
| > | difference is that MareaImage goups loads Marea apart from he
| > | BaseImage:
| > |
| > | group: 'MareaImage' with: #( 'BaseImage' 'Marea');
| > |
| > | so why Metacello needs in this case to sort or calcula the last
| > | version of Nautilus? what has this of difference with the first
| > | example?
| >
| > Mariano,
| >
| > Okay ... understanding what I haven't explained well enough is half
| > the battle:)
| >
| > I think that if you look at the fetch/load record for a load of
| > MareaImage into an empty image you will see that the package
| > 'Refactoring-Environment-lr.9' is actually loaded by another
| > project .... If you look at the spec for version 4.0 of Nautilus
| > you well see that 'Refactoring-Environment-lr.9' is
| > specified...BTW, version 4.0.4 of Nautilus does not specify
| > 'Refactoring-Environment' at all.
| >
| > Presumably during the load of BaseImage,
| > 'Refactoring-Environment-lr.9' is not loaded or perhaps the load
| > of Nautilus comes before the load of
| > 'Refactoring-Environment-lr.9'...
| >
| > Metacello always calculates the current version of a referenced
| > project before doing a load, but the current version is based upon
| > what Metacello thinks is loaded in the image...it takes packages
| > that have been fetched into account as well as packages that are
| > loaded in the image when it does it's calculation.
| >
| > When you load BaseImage and no 'Refactoring-Environment-lr.9' is
| > seen when calculating the current version of Nautilus, Metacello
| > goes ahead and loads version 4-04 of Nautilus.
| >
| > When you load MareaImage 'Refactoring-Environment-lr.9' is seen and
| > Metacello calculates the current version of Nautilus to be 4.0 ...
| > then it looks at the requested version 4-04 and sees that you are
| > requesting an earlier version and we are off to the races ...
| >
| > In general it is not a good practice for two different projects to
| > have specifications for the same package ... the versions are most
| > likely never in synch so even if it doesn't confuse Metacello
| > (noticeably) it will confuse you if you depend upon behaviour in a
| > particular package version ...
| >
| > Instead of a direct reference to the package, you should use a
| > project reference and then you can guarantee consistency...
|
| Why? if you depend on Foo-1 and Bar-2, and Bar-2 depends on Foo-2,
| you're in trouble. If you say you depend on Bar, you aren't correctly
| specifying your dependencies, and if you do, your configuration's
| inconsistent. If you could avoid having both the direct dependency
| and
| the indirect dependency on Foo you're safe, but I don't see how you
| can in the _general_ case avoid such a thing happening. (Properly
| handling the situation - letting both versions of Foo coexist - is
| not
| something we're ready to address in either Squeak or Pharo, even
| though it's not theoretically impossible.)
|
| frank

Frank,

Here is how you correctly reference a specific package from another project:

           spec
               project: 'RefactoringBrowser'
                   with: [
                           spec
                               className: 'ConfigurationOfRefactoringBrowser';
                               versionString: #'stable';
                               loads: #('Refactoring-Environment');
                               repository: 'http://www.squeaksource.com/MetacelloRepository' ].

Only 'Refactoring-Environment' and it's required packages and projects will be loaded... This way you will maintain consistency with RefactoringBrowser if and when you start to use the package.

Dale