versionString: #'stable'

Hi!

Some remark. In baselines generated by the toolkit, there is often this line:
versionString: #'stable';

Since a symbol is provided to versionString:, shouldn't this method called versionSymbol: or maybe version: ?

Other think, more important for me.
The toolkit generates some version with things like:
spec project: 'Mondrian' with: #'stable'.

In my opinion, it does not make sense to have 'stable' in a version. I would expect to have the stable version of Mondrian put here.
How comes this happens?
I can provide a scenario to reproduce this if this is not the intended behavior.

Cheers,
Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On Mar 3, 2011, at 5:33 AM, Alexandre Bergel wrote:

> Hi!
>
> Some remark. In baselines generated by the toolkit, there is often this line:
> versionString: #'stable';
>
> Since a symbol is provided to versionString:, shouldn't this method called versionSymbol: or maybe version: ?

Other than the fact that versionString is part of 10000's of configuration versions, I would agree. If I had it to do all over again and I could erase the memories of the current users I would use a different name ... Instead of worrying about the name of this method, let's make strides for ensuring that human beings never have to look at a version spec ... in fact eventually Configurations will/should be replaced by xml files or some other format...

>
> Other think, more important for me.
> The toolkit generates some version with things like:
> spec project: 'Mondrian' with: #'stable'.

I'm assuming that this is happening in a baseline specification?
>
> In my opinion, it does not make sense to have 'stable' in a version. I would expect to have the stable version of Mondrian put here.
> How comes this happens?

This is a good question ...

For packages in a baseline you don't bother specifying a specific mcz file ... that way when you load a baseline version you will get the latest mcz file ...

For project versions you used to either specify an explicit version or specified nothing ... when nothing was specified the latest version of a project is loaded, but loading the latest version of a project is not cool, because the latest version isn't platform specific --- #stable is the version that should be used whenever you want a platform independent "latest version"

Specifying an explicit version is just as uncool, for the same reason ... the version that you specify may not work for the platform that you are loading on ...

We do have a #bleedingEdge version that says load the #bleedingEdge for the platform that I am on ... for a project spec in a baseline using #bleedingEdge is the moral equivalent of not specifying an mcz file ... the default definition of #bleedingEdge is latest baseline, but you can specify a specific version for different platforms.

This brings me to the concept of loose and tight coupling. In Seaside30, the Grease project is tightly coupled ... a particular version of Seaside30 is expected to work with a particular version of Grease, so when I load a Seaside30 baseline I expect that the latest version of Seaside30 packages and the latest version of Grease packages get loaded , so the baseline in Seaside30 uses #bleedingEdge for Grease .... remember when you load a baseline version you are explicitly looking to get the latest stuff and if it is broken so be it...

OmniBrowser is different. Seaside30 uses OmniBrowser for one window, so this is a loose coupling ... It doesn't matter at all which version of OmniBrowser is loaded just as long as OmniBrowser is present. In this case you would use #stable to get a version that is known to work . _known to work_ is the key phrase ... using #stable is conservative version ,,

Now to answer your question:

In a baseline it is not normally correct to specify a literal version, one _should_ use either #stable or #bleedingEdge, so when the tool is picking a version to use in the baseline specification for a project it is _safest_ to pick #stable ... if there is not #stable version defined, then it will use #bleedingEdge.

As with all automated process, the default behavior is not what some folks want ... I would like to improve the way that projects and packages are specified in MetacelloBrowser ... the UI can prompt the user for options ... preferences can be set, etc.  and we can do a better job of specifying things the way the user intends ... remember the ultimate goal is to completely divorce the user from ever having to look at a configuration class ... unless they are curiuos:)

Dale