what is the status of metacello

>
>
> On Fri, Jan 7, 2011 at 9:04 AM, stephane ducasse
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hi dale
>
>     Happy new year. I would really like to see if we can push the use of
>     metacello
>     as support for distributions.
>     What is the status?
>     Can we push that?
>
>
> Stef, the symbolic versions (stable and blah) seems to be working. And
> dale modified all the confs of the dev image. Now, they are commited in
> another (dale can you remember us the url please) temp repo (to
> experiment).
> So...we just need 2 more things:
> 1) be able to copy all mzc of a project to another repo (to be self
> contained)
> 2) adapt Loader to take advantage of all these changes so that it is
> really easy to install
>
> I think we can live without 1) for a moment, and maybe even without 2)
>
> So Dale.....what do you think we should do?  just "merge" all your confs
> (included Pharo conf), and start to build the dev image using all stable
> versions?

> On 01/07/2011 12:04 AM, stephane ducasse wrote:
>> Hi dale
>>
>> Happy new year. I would really like to see if we can push the use of metacello
>> as support for distributions.
>> What is the status?
>> Can we push that?
>>
>> Stef
> Stef,
>
> I have been spending the last few days writing the blog post that will accompany the symbolic version release ... It's pretty close to being done ...optimistically I will release today, but more likely on monday...
>
> Dale

> Hi!
>
> I think that the term bleedingEdge and stable are applicable only to
> large software that do not have sufficient unit tests. For example,
> in the case of Moose (including all the tools it depends on), I
> cannot find a meaning to bleedingEdge. Each new version of Moose is
> considered as stable. The large amount of unit tests gives enough
> confidence regarding its reliability.
>
> As Lukas says, the last version is what you should load.
>
> Alexandre
>
>
> On 8 Jan 2011, at 14:49, Dale Henrichs wrote:
>
>> Stef,
>>
>> I agree ... #bleedingEdge and #stable are pretty clear, but
>> #development _is_ fuzzy ... as I am writing the blog post I am
>> coming to the conclusion that #development is   more useful as a
>> tag for tools than it is for users of a configuration ... we
>> already have the #development  blessings that indicates the version
>> is unstable ... developers should already know what version they
>> are working on and may or may not be using the #development
>> blessing anyway ...
>>
>> However, in writing the toolbox scripts for development support
>> I've found that it convenient to tag the development version so
>> scripts that do things like 'release' or 'update mcz files' are
>> easier ...
>>
>> Dale
>

>> Hi!
>>
>> I think that the term bleedingEdge and stable are applicable only to
>> large software that do not have sufficient unit tests. For example,
>> in the case of Moose (including all the tools it depends on), I
>> cannot find a meaning to bleedingEdge. Each new version of Moose is
>> considered as stable. The large amount of unit tests gives enough
>> confidence regarding its reliability.
>>
>> As Lukas says, the last version is what you should load.
>>
>> Alexandre
>>
>>
>> On 8 Jan 2011, at 14:49, Dale Henrichs wrote:
>>
>>> Stef,
>>>
>>> I agree ... #bleedingEdge and #stable are pretty clear, but
>>> #development _is_ fuzzy ... as I am writing the blog post I am
>>> coming to the conclusion that #development is   more useful as a
>>> tag for tools than it is for users of a configuration ... we
>>> already have the #development  blessings that indicates the version
>>> is unstable ... developers should already know what version they
>>> are working on and may or may not be using the #development
>>> blessing anyway ...
>>>
>>> However, in writing the toolbox scripts for development support
>>> I've found that it convenient to tag the development version so
>>> scripts that do things like 'release' or 'update mcz files' are
>>> easier ...
>>>
>>> Dale
>>
>
> Alexandre,
>
> the #bleedingEdge _is_ defined to load the latest version. The point of
> using symbolic version for the this is to allow the developers to
> explicitly define what "load latest of everything"means.
>
> The default definition of #bleedingEdge is:
>
>  load latest baseline version
>
> which works for most projects. For Seaside30, the correct packages
> aren't loaded if you use the default definition of #bleedingEdge, so I
> had to override the definition for #bleedingEdge to get the correct
> baseline version loaded.
>
> A while ago Doru called for a convention where every project defines a
> 'default' versions as is done for the Moose project. With the
> introduction of #bleedingEdge, we don't need developers to follow a
> convention ... the default definition of #bleedingEdge does what (I
> think) Doru was looking for which is:
>
>  make it possible to load the #bleedingEdge for every Metacello project
>
> As for the meaning of #stable ... frankly I don't think there is a single word that is completely sufficient:) ... I've been using the terms #stable, #bleedingEdge, and #development for months now and will be releasing 1.0-beta.28 very soon now, so it is a bit late to quibble about the terminology:)
>
> I prefer to take the approach:
>
>  1. make it work
>  2. make it right
>  3. make it fast
>
> and for Metacello I think we are still in the phase of "making it work" ... number one is "do symbolic versions help to solve the Pharo1.0/1.1/1.2 problem?"...in 6 months when we have more experience we can twiddle with terminology ... I fully expect that over time there will be a fair number of symbolic version names that are in common use (if you will note ... the implementation of symbolic versions is completely open), but just out of the gate I think it is important to keep it simple ... just introducing #stable as a replacement for latestVersion is a major improvement ...
>
> Dale

> Alexandre,
>
> I want to emphasize the fact that #bleedingEdge versions should only be loaded by the developers of a project ... The whole idea of the #stable version is to provide a target version that is known to work on a particular platform ... i.e., the name stable was chosen to reassure users (not developers) that they are loading a version that can be trusted.
>
> We need to encourage developers to specify #stable versions for the various platform versions. The stable version is the version that _they_ recommend users should load on a particular version of Pharo.
>
> Then we can tell users to install the #stable version of a project .... then we can write tools that assume the correct version to install of any given project is the _stable_ version ... then we can explicitly inform users that there is no stable version of a particular project on a particular version of Pharo .... then if I want my project to run on all versions of Pharo/Squeak/GemStone and my project depends upon OmniBrowser I know what version to specify (#stable) that will cause the correct version of OmniBrowser to be loaded as a dependency...
>
> The #bleedingEdge version will only work on one platform version... the version that the developers are using ... I'll wager that the #bleedingEdge version for Moose (or the 'default' version) will not function correctly on Pharo1.0 anymore, yet there are probably several literal versions that can be used on Pharo 1.0 and are actually stable on Pharo1.0...
>
> I know what Lukas says, but his recommendation is only correct for Pharo1.1 (whichever version of Pharo Lukas is currently doing his work and as long as you are not doing a load during a Seaside sprint:) For GLASS users the latest Seaside30 mcz files may not have been ported to GemStone yet, so it's a always bad idea to load the latest mcz files for Seasided30 on GLASS unless you are a developer ...
>
> This same kind of advice applies to folks running on Pharo1.0, Phar1.1, Pharo1.2 and so on....Once you have put a site into production using Pharo1.0 or Pharo1.1 (or Pharo1.2 once development starts on Pharo1.3) you cannot easily move your site/product to a new version of Pharo and we'd like to _not abandon_ folks who have gone into production...
>
> Unit tests do not guarantee stability either ... over Thanksgiving all of the unit tests passed for OmniBrowser on Pharo1.2, but an OB window wouldn't even open ... only the developers know what works and what doesn't and what they recommend and what they don't recommend ... and the way that they can communicate to the users of their project is to specify a #stable version where they define which version should be used on which platform .... and if the developer discovers that there is a bug that he/she wants to fix, he/she can release a new version, update the #stable specification and tell his/her users to update to the #stable version ...
>
> If Lukas chooses to define his #stable version as a #bleedingEdge version, then that's fine ... With symbolic version specifications he can also exclude the versions of Pharo that aren't supported just as easily as he can include the versions that are supported ... In the end I will just ask that he _define_ the #stable versions.
>
> With all of this said, I now think that 'stable' is the best name to use for this purpose:)

> On 01/09/2011 05:24 PM, Alexandre Bergel wrote:
>> Hi!
>>
>> I think that the term bleedingEdge and stable are applicable only to
>> large software that do not have sufficient unit tests. For example,
>> in the case of Moose (including all the tools it depends on), I
>> cannot find a meaning to bleedingEdge. Each new version of Moose is
>> considered as stable. The large amount of unit tests gives enough
>> confidence regarding its reliability.
>>
>> As Lukas says, the last version is what you should load.
>>
>> Alexandre
>>
>>
>> On 8 Jan 2011, at 14:49, Dale Henrichs wrote:
>>
>>> Stef,
>>>
>>> I agree ... #bleedingEdge and #stable are pretty clear, but
>>> #development _is_ fuzzy ... as I am writing the blog post I am
>>> coming to the conclusion that #development is   more useful as a
>>> tag for tools than it is for users of a configuration ... we
>>> already have the #development  blessings that indicates the version
>>> is unstable ... developers should already know what version they
>>> are working on and may or may not be using the #development
>>> blessing anyway ...
>>>
>>> However, in writing the toolbox scripts for development support
>>> I've found that it convenient to tag the development version so
>>> scripts that do things like 'release' or 'update mcz files' are
>>> easier ...
>>>
>>> Dale
>>
>
> Alexandre,
>
> the #bleedingEdge _is_ defined to load the latest version. The point of
> using symbolic version for the this is to allow the developers to
> explicitly define what "load latest of everything"means.
>
> The default definition of #bleedingEdge is:
>
>  load latest baseline version
>
> which works for most projects. For Seaside30, the correct packages
> aren't loaded if you use the default definition of #bleedingEdge, so I
> had to override the definition for #bleedingEdge to get the correct
> baseline version loaded.
>
> A while ago Doru called for a convention where every project defines a
> 'default' versions as is done for the Moose project. With the
> introduction of #bleedingEdge, we don't need developers to follow a
> convention ... the default definition of #bleedingEdge does what (I
> think) Doru was looking for which is:
>
>  make it possible to load the #bleedingEdge for every Metacello project
>
> As for the meaning of #stable ... frankly I don't think there is a single word that is completely sufficient:) ... I've been using the terms #stable, #bleedingEdge, and #development for months now and will be releasing 1.0-beta.28 very soon now, so it is a bit late to quibble about the terminology:)
>
> I prefer to take the approach:
>
>  1. make it work
>  2. make it right
>  3. make it fast
>
> and for Metacello I think we are still in the phase of "making it work" ... number one is "do symbolic versions help to solve the Pharo1.0/1.1/1.2 problem?"...in 6 months when we have more experience we can twiddle with terminology ... I fully expect that over time there will be a fair number of symbolic version names that are in common use (if you will note ... the implementation of symbolic versions is completely open), but just out of the gate I think it is important to keep it simple ... just introducing #stable as a replacement for latestVersion is a major improvement ...
>
> Dale
>

>
>
> On Sunday, January 9, 2011 5:24:21 PM UTC-8, Alexandre.Bergel wrote:
> Hi!
> I think that the term bleedingEdge and stable are applicable only to large software that do not have sufficient unit tests. For example, in the case of Moose (including all the tools it depends on), I cannot find a meaning to bleedingEdge. Each new version of Moose is considered as stable. The large amount of unit tests gives enough confidence regarding its reliability.
>
> As Lukas says, the last version is what you should load.
>
>
>
> Alexandre,
>
> I want to emphasize the fact that #bleedingEdge versions should only be loaded by the developers of a project ... The whole idea of the #stable version is to provide a target version that is known to work on a particular platform ... i.e., the name stable was chosen to reassure users (not developers) that they are loading a version that can be trusted.
>
> We need to encourage developers to specify #stable versions for the various platform versions. The stable version is the version that _they_ recommend users should load on a particular version of Pharo.
>
> Then we can tell users to install the #stable version of a project .... then we can write tools that assume the correct version to install of any given project is the _stable_ version ... then we can explicitly inform users that there is no stable version of a particular project on a particular version of Pharo .... then if I want my project to run on all versions of Pharo/Squeak/GemStone and my project depends upon OmniBrowser I know what version to specify (#stable) that will cause the correct version of OmniBrowser to be loaded as a dependency...
>
> The #bleedingEdge version will only work on one platform version... the version that the developers are using ... I'll wager that the #bleedingEdge version for Moose (or the 'default' version) will not function correctly on Pharo1.0 anymore, yet there are probably several literal versions that can be used on Pharo 1.0 and are actually stable on Pharo1.0...
>
> I know what Lukas says, but his recommendation is only correct for Pharo1.1 (whichever version of Pharo Lukas is currently doing his work and as long as you are not doing a load during a Seaside sprint:) For GLASS users the latest Seaside30 mcz files may not have been ported to GemStone yet, so it's a always bad idea to load the latest mcz files for Seasided30 on GLASS unless you are a developer ...
>
> This same kind of advice applies to folks running on Pharo1.0, Phar1.1, Pharo1.2 and so on....Once you have put a site into production using Pharo1.0 or Pharo1.1 (or Pharo1.2 once development starts on Pharo1.3) you cannot easily move your site/product to a new version of Pharo and we'd like to _not abandon_ folks who have gone into production...
>
> Unit tests do not guarantee stability either ... over Thanksgiving all of the unit tests passed for OmniBrowser on Pharo1.2, but an OB window wouldn't even open ... only the developers know what works and what doesn't and what they recommend and what they don't recommend ... and the way that they can communicate to the users of their project is to specify a #stable version where they define which version should be used on which platform .... and if the developer discovers that there is a bug that he/she wants to fix, he/she can release a new version, update the #stable specification and tell his/her users to update to the #stable version ...
>
> If Lukas chooses to define his #stable version as a #bleedingEdge version, then that's fine ... With symbolic version specifications he can also exclude the versions of Pharo that aren't supported just as easily as he can include the versions that are supported ... In the end I will just ask that he _define_ the #stable versions.
>
> With all of this said, I now think that 'stable' is the best name to use for this purpose:)
>
> Dale
>
>
>
>
>
>