about blessing: and others

hi dale

I have the impression that blessing: could be replace by better messages or a least that slowly we
could improve them.

Here is my experience:

in a baseline
        we should define a baseline using

        blessing: #baseline
       

but we never have to do it for  a version.


In version
we say
        blessing: #development/release

and it would be nicer to have

We could have

In a baseline
        baseline.

In a version
        version: #development

I would really like to have an intention revealing API.

For example versionString: to me is also misleading because I would prefer
        developmentStatus:


Finally instead of file: it would be good to have package:
and I was wondering why we could not have load: instead of loads:
         spec
        className: 'ConfigurationOfCoolBrowser';
               versionString: '0.6';
               loads: #('ALL' );
               file: 'CoolBrowser-Metacello';
               repository: 'http://www.example.com/CoolBrowser' ].

=>
         spec
        className: 'ConfigurationOfCoolBrowser';
               version: '0.6';
               load: #('ALL' );
               package: 'CoolBrowser-Metacello';
               repository: 'http://www.example.com/CoolBrowser' ].



Finally

I would like to know what is the minimal mandatory information when we follow all the conventions }

\begin{code}{}
ConfigurationOfCoolToolSet >>baseline01: spec
      <version: '0.1-baseline'>
      spec for: #common do: [
             spec repository: 'http://www.example.com/CoolToolSet'.
             spec project: 'CoolBrowser ALL' with: [
                           spec
                              versionString: '0.6';
                              repository:}! 'http://www.example.com/CoolBrowser' ]
             spec
                    package: 'CoolToolSet-Core' with: [ spec requires: 'CoolBrowser ALL' ];
                    package: 'CoolToolSet-Tests' with: [ spec requires: 'CoolToolSet-Core' ]].

Do I need ALL? here.






Stef

----- Original Message -----
| From: "stephane ducasse" <[hidden email]>
| To: "Dale Henrichs" <[hidden email]>, [hidden email]
| Sent: Sunday, October 2, 2011 12:47:16 PM
| Subject: about blessing: and others
|
| hi dale
|
| I have the impression that blessing: could be replace by better
| messages or a least that slowly we
| could improve them.
|
| Here is my experience:
|
| in a baseline
| we should define a baseline using
|
| blessing: #baseline
|
|
| but we never have to do it for  a version.
|
|
| In version
| we say
| blessing: #development/release
|
| and it would be nicer to have
|
| We could have
|
| In a baseline
| baseline.

I think this makes a lot of sense.

|
| In a version
| version: #development

I'm afraid that this form will confuse folks, since #version: is used as part of the load scripts ....

Perhaps we should have messages: #baseline, #development, #release.

And it is an error to not have one of those three messages.

|
| I would really like to have an intention revealing API.
|
| For example versionString: to me is also misleading because I would
| prefer
| developmentStatus:

I'm a bit confused here. This is a case where I think it makes sense to use #version: instead of #versionString:, since #version: is consistent with the use of #version: in a load script ... the same arguments are used.
|
|
| Finally instead of file: it would be good to have package:
| and I was wondering why we could not have load: instead of loads:
| spec
|         className: 'ConfigurationOfCoolBrowser';
|                versionString: '0.6';
|                loads: #('ALL' );
|                file: 'CoolBrowser-Metacello';
|                repository: 'http://www.example.com/CoolBrowser' ].
|
| =>
| spec
|         className: 'ConfigurationOfCoolBrowser';
|                version: '0.6';
|                load: #('ALL' );
|                package: 'CoolBrowser-Metacello';
|                repository: 'http://www.example.com/CoolBrowser' ].

#load: and #package: are good ideas....
|
|
|
| Finally
|
| I would like to know what is the minimal mandatory information when
| we follow all the conventions.

Very good idea ... ping me for this in a separate thread (once we've settled on the changes we want to make).

|
| \begin{code}{}
| ConfigurationOfCoolToolSet >>baseline01: spec
|       <version: '0.1-baseline'>
|       spec for: #common do: [
|              spec repository: 'http://www.example.com/CoolToolSet'.
|              spec project: 'CoolBrowser ALL' with: [
|                            spec
|                               versionString: '0.6';
|                               repository:}!
|                               'http://www.example.com/CoolBrowser' ]
|              spec
|                     package: 'CoolToolSet-Core' with: [ spec
|                     requires: 'CoolBrowser ALL' ];
|                     package: 'CoolToolSet-Tests' with: [ spec
|                     requires: 'CoolToolSet-Core' ]].
|
| Do I need ALL? here.

Are you asking whether 'CoolBrowser ALL' is needed or are you asking about whether the project should be named 'CoolBrowser Alll', or ?

Dale

> | We could have
> |
> | In a baseline
> | baseline.
>
> I think this makes a lot of sense.

good.
I'm happy.

or we could have
        declareBaseline
        declareVersion:


or baseline, developmentVersion, releasedVersion

anything that show ok version and baseline are the key keywords
> |
> | I would really like to have an intention revealing API.
> |
> | For example versionString: to me is also misleading because I would
> | prefer
> | developmentStatus:
>
> I'm a bit confused here. This is a case where I think it makes sense to use #version: instead of #versionString:, since #version: is consistent with the use of #version: in a load script ... the same arguments are used.

Yes I was mixing text the example is correct


Excellent

No that
>   spec
> |                               versionString: '0.6';
> |                               repository: 'http://www.example.com/CoolBrowser

is really the minimal information we need.

Dale I changed a lot the chapter to go with the simple first.
About the changes let me know.

Stef










>
> Dale