symbolic versions

First, I assume that you've read Mariano's mail (Metacello as a package management system for Pharo - http://forum.world.st/Metacello-as-a-package-management-system-for-Pharo-td2547635.html#a2547635) where Mariano discussed the problems and proposed solutions.

I've been working the last couple of days on the #stableVersion solution (solution a). I've got a working implementation, but I'd like to share the solution with you folks before I make any additional moves (I've got a basic set of tests, but I'd want to add more tests before letting too many folks play with it).

The basic concept is that we'd introduce the idea of _symbolic versions_. In other systems I think that the functionality would be implemented as some kind of tag...For solving the Pharo package management problem, we need to have conditional tags and for now I'm calling them _symbolic versions_ (emphasizing the use of symbols instead of strings).

To define a _symbolic version_ you add a method like the following to your ConfigurationOf class:

 stableVersion: spec
       <symbolicVersion: #stable>
       
       spec for: #'common' version: '4.3'.
       spec for: #'pharo1.x' version: '4.0'.
       spec for: #'pharo1.0.x' version: '4.1'.
       spec for: #'pharo1.1.x' version: '4.2'.
       spec for: #'pharo1.2.x' version: '4.3'.

The pragma announces that this method defines a #symbolicVersion: named #stable and the body of the method defines the conditional mapping of #stable to a specific version (note that the version can be another _symbolic version_).

_symbolic versions_ can be used anywhere that a version string is used (including configurations) so the the following expression when evaluated would load a different version depending upon which platform the expression was executed on:

 (ConfigurationOfXXX project version: #stable) load.

would load the following versions on the given platform:

 GemStone   - version 4.3
 Squeak     - version 4.3
 Pharo1.0   - version 4.1
 Pharo1.1   - version 4.2
 Pharo1.2   - version 4.3

With _symbolic versions_ a project could define symbolic versions above and beyond the expected (default) symbolic versions: #stable, #development, #bleedingEdge. For these three symbolic versions, there would be default behavior specified if no definition is provided:

  stable            - latest non-development release
  development (???) - latest development release .. so modify the
                      message formerly known as #latestVersion to be
                      #development ... which would provide the
                      latest development version (unless there is a
                      later #stableVersion)
  bleedingEdge      - latest version of every package/project -
                      uses the mechanism that we decide to use for
                      naming the 'default' version
(see http://forum.world.st/last-latest-stable-Version-bleedingEdge-td2530571.html#a2530571)

I expect that for projects like Seaside it might make sense to define a symbolic versions #'3.0' and #'3.1' once development on 3.1 takes place so that folks could track the stable version of #'3.0' or #'3.1' depending upon their preferences....In this case the #stable version and #'3.0' might be the same, while folks could track the stable version of #'3.1' ... then when 3.1 becomes the preferred stable version then #stable would redefined to be the same as #'3.1'...

I prefer symbolic versions to embedding the specification in the version itself (alternative b in Mariano's mail), because it is really easy to tell (in one spot) what versions are associated with which platform (otherwise it would be difficult to determine with the current tools).

I also think that a version should be aware of the _symbolic versions_ that reference it, but I haven't implemented this.

The other advantage is that old versions of Metacello won't choke on configurations that have symbolic versions specified (although to use a symbolic version, you'll need a new version of Metacello loaded)...

Let me know what you think...

Dale

Mariano Martinez Peck wrote:

On Fri, Sep 24, 2010 at 1:40 AM, Dale Henrichs <[hidden email] <mailto:[hidden email]>> wrote:

   First, I assume that you've read Mariano's mail (Metacello as a
   package management system for Pharo -
   http://forum.world.st/Metacello-as-a-package-management-system-for-Pharo-td2547635.html#a2547635)
   where Mariano discussed the problems and proposed solutions.

   I've been working the last couple of days on the #stableVersion
   solution (solution a). I've got a working implementation, but I'd
   like to share the solution with you folks before I make any
   additional moves (I've got a basic set of tests, but I'd want to add
   more tests before letting too many folks play with it).

   The basic concept is that we'd introduce the idea of _symbolic
   versions_. In other systems I think that the functionality would be
   implemented as some kind of tag...For solving the Pharo package
   management problem, we need to have conditional tags and for now I'm
   calling them _symbolic versions_ (emphasizing the use of symbols
   instead of strings).

   To define a _symbolic version_ you add a method like the following
   to your ConfigurationOf class:

    stableVersion: spec
          <symbolicVersion: #stable>
                     spec for: #'common' version: '4.3'.
          spec for: #'pharo1.x' version: '4.0'.
          spec for: #'pharo1.0.x' version: '4.1'.
          spec for: #'pharo1.1.x' version: '4.2'.
          spec for: #'pharo1.2.x' version: '4.3'.


I like it. Althoguht I would prefer to have a block instead of a string:

 stableVersion: spec
      <symbolicVersion: #stable>
             spec for: #'common' do: [ self version: '4.3'].
      spec for: #'pharo1.2.x' do: [ self error: 'Project X is not supported for Pharo Y'].

I think a block could work, I just thought that the #for:version: was more concise ... I would favor a block if we forsee the need to include additional parameters when specifying a symbolic version, but at the moment I can't think of any ...

What I mean is that I would like to throw an error for example, when you are trying to load a stable version in a Pharo that doesn't work.

I've been thinking that I ought to throw errors in general for missing versions (returning nil is a hangover from my FORTRAN days:), so I would rather throw an error at lookup time for the symbolic version or the string version.

Even more, what would happen in the case of your example, If I am in Pharo 1.3, and I do
 (ConfigurationOfXXX project version: #stable)

what will answer that?   I would expect an error saying "There is no stable version associated for this platform" or something like that.

Actually in the case of the stable version, I was imagining that we would have a default that would return #latestVersion (as defined currently),

so that folks could consistently use #stable, #development, and #bleedingEdge whether or not the config defined tem explicitly. For symbolic versions outside of the standard symbolic versions an error is appropriate.

Another thing people asked in the thread I sent, is to support <, >, >=, etc....

So I can do something like:

spec for: #'>= pharo1.2.' do: [ self version: '4.3'].

or maybe an error, it is just an example:

spec for: #'>= pharo1.2.' do: [ self  'Not supported'].

Buy I think this can be a step forward...not right now.

This is worth considering ... for the new version scheme work that I was going to finish for Metacello 1.0, I was thinking about allowing folks to define the sort order explicitly (as an option) I should think about how the symbolic versions would play in this world ... perhaps that would argue for additional (optional) parameters when defining the symbolic version?

 
   The pragma announces that this method defines a #symbolicVersion:
   named #stable and the body of the method defines the conditional
   mapping of #stable to a specific version (note that the version can
   be another _symbolic version_).

   _symbolic versions_ can be used anywhere that a version string is
   used (including configurations) so the the following expression when
   evaluated would load a different version depending upon which
   platform the expression was executed on:

    (ConfigurationOfXXX project version: #stable) load.


So...we have to options, be forced to call the method #stableVersion or put any name and use the pragma...for me it is the same.

What I don't understand is, wuld I be able to do:

 ConfigurationOfXXX project stableVersion load.

or that wouldn't work?  because if it doesn't work it is different from latestVersion or lastVersion and I guess users will be confused.

#latestVersion and #lastVersion will remain and will be deprecated after 1.0 is released. #stableVersion will exist, but it will be defined as:

 ConfigurationOfXXX project version: #stable.

And if no #stable version is defined, the default is #latestVersion.

So #bleedingEdgeVersion and #stableVersion as methods implemented in the project will continue to exist as shorthand methods.

The main reason that we need to have symbolic versions is so that the version for a project reference can specified as the #stableVersion or #bleedingEdge ...

As I think about perhaps, we should remove the shorthand methods for #stableVersion and #bleedingEdgeVersion and expect people to use the symbolic versions ... what do you think?

The symbolic version approach is much more flexible than the message-based version shorthands.

Thoughts?

Dale

El vie, 24-09-2010 a las 09:50 -0700, Dale Henrichs escribió:

> Mariano Martinez Peck wrote:
> >
> >
> > On Fri, Sep 24, 2010 at 1:40 AM, Dale Henrichs <[hidden email]
> > <mailto:[hidden email]>> wrote:
> >
> >     First, I assume that you've read Mariano's mail (Metacello as a
> >     package management system for Pharo -
> >     http://forum.world.st/Metacello-as-a-package-management-system-for-Pharo-td2547635.html#a2547635)
> >     where Mariano discussed the problems and proposed solutions.
> >
> >     I've been working the last couple of days on the #stableVersion
> >     solution (solution a). I've got a working implementation, but I'd
> >     like to share the solution with you folks before I make any
> >     additional moves (I've got a basic set of tests, but I'd want to add
> >     more tests before letting too many folks play with it).
> >
> >     The basic concept is that we'd introduce the idea of _symbolic
> >     versions_. In other systems I think that the functionality would be
> >     implemented as some kind of tag...For solving the Pharo package
> >     management problem, we need to have conditional tags and for now I'm
> >     calling them _symbolic versions_ (emphasizing the use of symbols
> >     instead of strings).
> >
> >     To define a _symbolic version_ you add a method like the following
> >     to your ConfigurationOf class:
> >
> >      stableVersion: spec
> >            <symbolicVersion: #stable>
> >
> >            spec for: #'common' version: '4.3'.
> >            spec for: #'pharo1.x' version: '4.0'.
> >            spec for: #'pharo1.0.x' version: '4.1'.
> >            spec for: #'pharo1.1.x' version: '4.2'.
> >            spec for: #'pharo1.2.x' version: '4.3'.
> >
> >
> > I like it. Althoguht I would prefer to have a block instead of a string:
> >
> >  stableVersion: spec
> >        <symbolicVersion: #stable>
> >
> >        spec for: #'common' do: [ self version: '4.3'].
> >        spec for: #'pharo1.2.x' do: [ self error: 'Project X is not
> > supported for Pharo Y'].
>
> I think a block could work, I just thought that the #for:version: was
> more concise ... I would favor a block if we forsee the need to include
> additional parameters when specifying a symbolic version, but at the
> moment I can't think of any ...
>
> >
> >
> > What I mean is that I would like to throw an error for example, when you
> > are trying to load a stable version in a Pharo that doesn't work.
>
> I've been thinking that I ought to throw errors in general for missing
> versions (returning nil is a hangover from my FORTRAN days:), so I would
> rather throw an error at lookup time for the symbolic version or the
> string version.
>
> >
> > Even more, what would happen in the case of your example, If I am in
> > Pharo 1.3, and I do
> >  (ConfigurationOfXXX project version: #stable)
> >
> > what will answer that?   I would expect an error saying "There is no
> > stable version associated for this platform" or something like that.
>
> Actually in the case of the stable version, I was imagining that we
> would have a default that would return #latestVersion (as defined
> currently), so that folks could consistently use #stable, #development,
> and #bleedingEdge whether or not the config defined tem explicitly. For
> symbolic versions outside of the standard symbolic versions an error is
> appropriate.
>
> >
> > Another thing people asked in the thread I sent, is to support <, >, >=,
> > etc....
> >
> > So I can do something like:
> >
> > spec for: #'>= pharo1.2.' do: [ self version: '4.3'].
> >
> > or maybe an error, it is just an example:
> >
> > spec for: #'>= pharo1.2.' do: [ self  'Not supported'].
> >
> > Buy I think this can be a step forward...not right now.
>
> This is worth considering ... for the new version scheme work that I was
> going to finish for Metacello 1.0, I was thinking about allowing folks
> to define the sort order explicitly (as an option) I should think about
> how the symbolic versions would play in this world ... perhaps that
> would argue for additional (optional) parameters when defining the
> symbolic version?
>
> >
> >
> >
> >     The pragma announces that this method defines a #symbolicVersion:
> >     named #stable and the body of the method defines the conditional
> >     mapping of #stable to a specific version (note that the version can
> >     be another _symbolic version_).
> >
> >     _symbolic versions_ can be used anywhere that a version string is
> >     used (including configurations) so the the following expression when
> >     evaluated would load a different version depending upon which
> >     platform the expression was executed on:
> >
> >      (ConfigurationOfXXX project version: #stable) load.
> >
> >
> > So...we have to options, be forced to call the method #stableVersion or
> > put any name and use the pragma...for me it is the same.
> >
> > What I don't understand is, wuld I be able to do:
> >
> >  ConfigurationOfXXX project stableVersion load.
> >
> > or that wouldn't work?  because if it doesn't work it is different from
> > latestVersion or lastVersion and I guess users will be confused.
>
> #latestVersion and #lastVersion will remain and will be deprecated after
> 1.0 is released. #stableVersion will exist, but it will be defined as:

But why don't better to deprecated in a pre 1.0 version and release
version 1.0 without them altogether.

The 1.0 is the real release intende
for wide usage and including methods for compatiblity with pre-1.0
functionality may not be advisable, at least for the new configuration
created. Of course this will impact the documentation, but, anyway the
documentation will need to be documentated for this new version stuff to
be used.

>
>    ConfigurationOfXXX project version: #stable.
>
> And if no #stable version is defined, the default is #latestVersion.
>
> So #bleedingEdgeVersion and #stableVersion as methods implemented in the
> project will continue to exist as shorthand methods.
>
> The main reason that we need to have symbolic versions is so that the
> version for a project reference can specified as the #stableVersion or
> #bleedingEdge ...
>
> As I think about perhaps, we should remove the shorthand methods for
> #stableVersion and #bleedingEdgeVersion and expect people to use the
> symbolic versions ... what do you think?

I prefer to use only symbolic versions and put aside the shorthand
methods.

>
> The symbolic version approach is much more flexible than the
> message-based version shorthands.
>
> Thoughts?

Other thing to consider for the 1.0 release is the not so common but
sometimes used load method that try to guess the version in some
published Configuration.
I think that if it going to be supported and endorsed, at least a couple
of guidelines about the intended functionality should be stated. This
way it will avoid that this method be used in some heterogeneous way for
different Configurations.

Cheers
>
> Dale

--
Miguel Cobá
http://miguel.leugim.com.mx

Mariano Martinez Peck wrote:

On Fri, Sep 24, 2010 at 6:50 PM, Dale Henrichs <[hidden email] <mailto:[hidden email]>> wrote:

   Mariano Martinez Peck wrote:



       On Fri, Sep 24, 2010 at 1:40 AM, Dale Henrichs
       <[hidden email] <mailto:[hidden email]>

       <mailto:[hidden email] <mailto:[hidden email]>>> wrote:

          First, I assume that you've read Mariano's mail (Metacello as a
          package management system for Pharo -
                 http://forum.world.st/Metacello-as-a-package-management-system-for-Pharo-td2547635.html#a2547635)
          where Mariano discussed the problems and proposed solutions.

          I've been working the last couple of days on the #stableVersion
          solution (solution a). I've got a working implementation, but I'd
          like to share the solution with you folks before I make any
          additional moves (I've got a basic set of tests, but I'd want
       to add
          more tests before letting too many folks play with it).

          The basic concept is that we'd introduce the idea of _symbolic
          versions_. In other systems I think that the functionality
       would be
          implemented as some kind of tag...For solving the Pharo package
          management problem, we need to have conditional tags and for
       now I'm
          calling them _symbolic versions_ (emphasizing the use of symbols
          instead of strings).

          To define a _symbolic version_ you add a method like the
       following
          to your ConfigurationOf class:

           stableVersion: spec
                 <symbolicVersion: #stable>
                            spec for: #'common' version: '4.3'.
                 spec for: #'pharo1.x' version: '4.0'.
                 spec for: #'pharo1.0.x' version: '4.1'.
                 spec for: #'pharo1.1.x' version: '4.2'.
                 spec for: #'pharo1.2.x' version: '4.3'.


       I like it. Althoguht I would prefer to have a block instead of a
       string:

        stableVersion: spec
             <symbolicVersion: #stable>
                    spec for: #'common' do: [ self version: '4.3'].
             spec for: #'pharo1.2.x' do: [ self error: 'Project X is
       not supported for Pharo Y'].


   I think a block could work, I just thought that the #for:version:
   was more concise ... I would favor a block if we forsee the need to
   include additional parameters when specifying a symbolic version,
   but at the moment I can't think of any ...


I agree that #for:version: is more concise. I only "needed" a block in order to do other stuff, like throwing an error. But if that is handled by Metacello then maybe I don't need a block.
Do you image other uses of the block?  because it may tempt people to put code there that are platform specific but nothing to do with stableVersion.

 



       What I mean is that I would like to throw an error for example,
       when you are trying to load a stable version in a Pharo that
       doesn't work.


   I've been thinking that I ought to throw errors in general for
   missing versions (returning nil is a hangover from my FORTRAN
   days:), so I would rather throw an error at lookup time for the
   symbolic version or the string version.


EXCELLENT!!! I much MUCH prefer throwing an error than answering nil :)
 



       Even more, what would happen in the case of your example, If I
       am in Pharo 1.3, and I do
        (ConfigurationOfXXX project version: #stable)

       what will answer that?   I would expect an error saying "There
       is no stable version associated for this platform" or something
       like that.


   Actually in the case of the stable version, I was imagining that we
   would have a default that would return #latestVersion (as defined
   currently),

I am not sure if I agrre. If people uses stableVersion is because they DO want stable versions. And if there is none, then an error should eb thrown. If someone wants a stableVersion AND in case there is none, it wants latestVersion anyway, then it should be done explicitly but not by default. Imagine that #latestVersion can not even work in the current Pharo he is trying to load....then??? what STABLE version we are talking about?  ;)   ... Sorry I just put my user hat :)
 I wouldn't put any default for #stableVersion.

The argument for a default is that it does encourage people to use the construct when referencing a project .

The argument against is as you say ... if there is no stable version defined, then there is no stable version.

I'm on the fence for a default, but lean towards no default as you suggest .... I think that #latestVersion and #lastVersion were appealing shortcuts, but in the end caused confusion and were not explicit declarations and therefore were subject to unintended changes in behaviour ...

On the other hand, it is awfully convenient to be able to define a project version using #stableVersion .... then you don't have to edit the config as the #stableVersion progresses ...

Tempting to make defining a stableVersion required if we don't have a default.

   so that folks could consistently use #stable, #development, and
   #bleedingEdge whether or not the config defined tem explicitly. For
   symbolic versions outside of the standard symbolic versions an error
   is appropriate.



       Another thing people asked in the thread I sent, is to support
       <, >, >=, etc....

       So I can do something like:

       spec for: #'>= pharo1.2.' do: [ self version: '4.3'].

       or maybe an error, it is just an example:

       spec for: #'>= pharo1.2.' do: [ self  'Not supported'].

       Buy I think this can be a step forward...not right now.


   This is worth considering ... for the new version scheme work that I
   was going to finish for Metacello 1.0, I was thinking about allowing
   folks to define the sort order explicitly (as an option) I should
   think about how the symbolic versions would play in this world ...
   perhaps that would argue for additional (optional) parameters when
   defining the symbolic version?


then we may need a block?  :)
Anyway, we should go step by step. We can start without blocks and without <, >, etc....and we try this, we try the different repositories and copies them there, the loader...etc. Then for Metacello 1.1 we can add this if necessary.

Yeah, it's worth thinking about, but simple is important and moving slowly is a good idea....add things when we know that we need them...

 


                   The pragma announces that this method defines a #symbolicVersion:
          named #stable and the body of the method defines the conditional
          mapping of #stable to a specific version (note that the
       version can
          be another _symbolic version_).

          _symbolic versions_ can be used anywhere that a version string is
          used (including configurations) so the the following
       expression when
          evaluated would load a different version depending upon which
          platform the expression was executed on:

           (ConfigurationOfXXX project version: #stable) load.


       So...we have to options, be forced to call the method
       #stableVersion or put any name and use the pragma...for me it is
       the same.

       What I don't understand is, wuld I be able to do:

        ConfigurationOfXXX project stableVersion load.

       or that wouldn't work?  because if it doesn't work it is
       different from latestVersion or lastVersion and I guess users
       will be confused.


   #latestVersion and #lastVersion will remain and will be deprecated
   after 1.0 is released. #stableVersion will exist, but it will be
   defined as:

    ConfigurationOfXXX project version: #stable.

   And if no #stable version is defined, the default is #latestVersion.

   So #bleedingEdgeVersion and #stableVersion as methods implemented in
   the project will continue to exist as shorthand methods.

   The main reason that we need to have symbolic versions is so that
   the version for a project reference can specified as the
   #stableVersion or #bleedingEdge ...


ahhhh good one :)
 

   As I think about perhaps, we should remove the shorthand methods for
   #stableVersion and #bleedingEdgeVersion and expect people to use the
   symbolic versions ... what do you think?


Yes, but not rigth now. I would deprecated them after 1.0. I wouldn't release 1.0 with already deprecated memthods

I can buy that argument...

 

   The symbolic version approach is much more flexible than the
   message-based version shorthands.


agree

 
   Thoughts?

   Dale

Mariano,

Very good points ... you are absolutely right that having a silent default will just cause more confusion ...

So that leaves with the problem of how to specify alternate behavior via  message sends perhaps.

So far I've been trying to limit the data in the configuration to static information as much as possible ... doIts have the exception, but now it _is_ appearing that providing a mechanism for calling/implementing methods would be useful.

As a first cut (without too much thought:), I'd be inclined to have the semantics of a symbolic version be:

 1. look up a direct mapping for the symbolic version

 2. attempt to use the symbolic version as a message selector where the
    result must be a MetacelloVersion

 3. throw a version not found error

What do you think?

Dale

Tudor Girba wrote:

Hi,

Sorry for the late reply, but I was a bit swamped into other
projects.

I read the thread now, but I am not sure I understand how this would
work for the bleedingEdge behavior.

Will I have to write something like this?

ConfigurationOfMoose>>bleedingEdgeVersion: spec <symbolicVersion:
#bleedingEdge> spec for: #'common' version: 'default'.

My expectations for bleedingEdge is that there will be combination of
several things done:

 1. There will be a bleedingEdgeVersion method in the default
    ConfigurationOf template that looks something like the following
    (as suggested by Sean):

    bleedingEdgeVersion
    <symbolicVersion: #bleedingEdge>

    versions := self map values versions select: [ :version |
        '*baseline*' match: version name ].
    ^ baselines detectMax: [ :version | version ].

 2. There will be an optional method that may specify platform-specific
    bleedingEdge versions:

    bleedingEdgeVersion:spec
    <symbolicVersion: #bleedingEdge>

    spec for: #'pharo1.0.x' version: 'baseline-1.0'.
    spec for: #'pharo1.1.x' version: 'baseline-1.1'.

Using the above as a example, the following expression would give
different results based upon which version of Pharo the expression is
evaluated in:

 (ConfigurationOfX project version: #bleedingEdge) load.

On Pharo1.0, version 'baseline-1.0' would be loaded.
On Pharo1.1, version 'baseline-1.1' would be loaded.
On Pharo1.2 and beyond, the algorithm in step one would be applied.

Sooo for Moose, the default #bleedingEdgeVersion is what you want and you'd not need to do anything special (i.e., no need to implement #.bleedingEdgeVersion:)

I am not sure what this will bring for the "default" case. My goal is
to load the latest version of packages present in the latest baseline
:). Now, because there was no way to refer to such a behavior, we
introduced "default" as the place that always shows the most recent
baseline. Having the method as above is just another indirection to
the "default".

One of the reasons for allowing messages to be sent to resolve symbolicVersions is to provide for a way to specify this behavior...presumably you can move away from having 'default' versions in the future ... their use will be replaced by the #bleedingEdge version.

Another point is that it looks to me like you will have only one
pragma like <symbolicVersion: #stableVersion> for the entire
configuration class. This would go against the "immutability" of
descriptions, achieved until now. This immutability is nice because
it enables you to create tools easily. Would it not be an idea to
have this description in the actual version: ConfigurationOfX>>versionY: spec <stableVersion: 'Y'>

The problem that we're trying to solve with symbolicVersions and the <symbolicVersion: #stableVersion> pragma is that a different version of the project is considered the #stableVersion depending upon the platform you are running on (Pharo1.0 vs Pharo1.2)....which implies three things:

 1. Multiple versions _will_ be tagged as a #stableVersion
 2. only one version can be the #stableVersion in a given instance
    (config plus platform ... config plus attributes)
 3. over time the versions _are_ immutable, while the #stableVersion
    _is_ expected to changed.

So separating out the symbolicVersion specification in a separate method gives better visibility of which versions are associated with which symbolic version. It also reduces the likelihood that duplicate specifications will occur.

How are these pragmas different from the blessing levels that already
exists?

SymbolicVersions are conditional and blessings are not ... the same problem that exists with the <stableVersion: 'Y'> pragma ... The important aspect is that the value is different depending upon which platform you are on...

If you still want to go with the original design, why have a pragma
when you should only have one pragma per class? I believe this can
lead to confusions in which we have multiple methods specifying
stable versions. Why not just a set of methods?

I'm not sure that I understand what you are getting at here. It would be nice if we could get out a white board and talk this over face to face ...

To summarize what I am thinking ...

#stableVersion is an explicit declaration for the dynamic concept: "load the latest released version of the project for the platform that I'm running on"

#bleedingEdgeVersion an explicit declaration for the dynamic concept: "load the latest baseline version."

The real value for symbolicVersions is not only that someone can explicitly load the #stableVersion, but another project can specify the #stableVersion in it's project reference ... something that cannot be done at all today.

I'm imagining that we will need to expand the symbolicVersion concept to include version-specific symbolicVersions:

 - #'3.0' defined as: "load the latest version of 3.0"
 - #'3.1' defined as: "load the latest version of 3.1"

This type of distinction would have been necessary for Seaside2.8 and Seaside2.9 where projects would have wanted to distinguish between stable versions of 2.8 and 2.9 independent of platform.

Note that the spec for #'3.1' at the very beginning of development will probably be #bleedingEdgeVersion, however, once folks begin using 3.1 in production applications, the spec should be changed to #stableVersion until development of 3.2 begins and the cycle starts again. With the current proposal, it is possible to define #'3.0', #'3.1', #stableVersion, #bleedingEdgeVersion explicitly or algorithmically.

The literalVersion is an explicit declaration for a bunch of code that is functionally equivalent. Version '3.1' is expected to have the same set of functionality no matter which platform you are working on.

The symbolicVersion is an explicit declaration of intent. In the current version of Metacello the only way to express intent is via the shorthand load methods: #lastVersion and #latestVersion. Doru, your desire for the 'default' conventions was aimed at being able to explicitly declare the intention to "load the latest version of all packages/projects".

I think it is important that with symbolicVersions that we not restrict the range of intent (as was done with #lastVersion and #latestVersion). Moving forward I expect that we will be refining and expanding intent.

It is also important to separate intent from the literalVersion specification. Version '3.1' is version '3.1' regardless of intent. In fact I expect that the intent for 3.1 will change over time, but I never expect version the specification of literalVersion 3.1 to change over time.

Blessings were an initial cut at intent. Currently there are 4 useful blessings (in my experience):

 - #development
 - #broken
 - #baseline
 - none of the above (or #release)

blessings aren't flexible enough to cover the range of intent that we are seeing now:

 - latest version that should be used on the version of Pharo that I'm
   loading the code into (#stableVersion)
 - latest version of every package/project for this project
   (#bleedingEdge)
 - latest minor version of the version 'X.0' (#'3.0')

I claim that there are two different mechanisms that must be used in specifying intent:

 - explicit declaration of an explicit definition
 - explicit declaration of an algorithmic definition

#bleedingEdge is the obvious example that requires an explicit declaration of an algorithmic definition. We can choose to hard-wire the knowledge of #bleedingEdge into Metacello or we can allow the user to define the algorithm as part of the ConfigurationOf. I think that it makes sense to allow the definition of the algorithm as part of the Configuration. Repeating the example used earler, here's how I would sugegest we specify the algorithmic definition:

    bleedingEdgeVersion
    <symbolicVersion: #bleedingEdge>

    versions := self map values versions select: [ :version |
        '*baseline*' match: version name ].
    ^ baselines detectMax: [ :version | version ].


#stableVersion is the obvious example that requires an explicit declaration of an explicit definition. Here's how I would suggest we specify the explicit defintions for ConfigurationOfOmniBrowser (at the point in time not too long ago when the only option was to load the bleedingEdge for Pharo 1.2):

    stableVersion:spec
    <symbolicVersion: #stableVersion>

    spec for: #'pharo1.0.x' version: '1.1.4'.
    spec for: #'pharo1.1.x' version: '1.1.5'.
    spec for: #'pharo1.2.x' version: #bleedingEdgeVersion.

Sooo, I assume that the case for having symbolicVersions and literalVersions is a solid one. I am open to discussions on alternatives to symbolicVersions, but let's be clear in the subject line that the thread is about alternatives to symbolicVersions....

I'm clearly biased in favor of keeping the specification of symbolicVersions separate from the literalVersion specifications, so if you have a argument in favor of combining the specs, then again make a clear statement in the subject line.

I do think that there is room for improvement in the specification of symbolicVersions and am interested in hearing alternate proposals with clear statements in the subject line.

It's really too bad that we can't have face to face discussions at a white board ... I always have a difficult time keeping track of the multiple threads of conversations in emails ... at the whiteboard, you can always grab the marker out of my hand and make your point ... it's just not possible with emails ...

Dale

Mariano,

Yes I think you are right that #stableVersion should be used 99% of the time ... but that's when I think that #'3.0' and #'3.1' style stableVersions will become useful ... #stableVersion will stick on the 3.0 branch until 3.1 is released and then #stable version will track the 3.1 branch ... however, there may be folks that will continue using the 3.0 branch in which case a #'3.0' symbolic version will be useful ...

The nice thing is that the symbolic versions are platform-specific, so in the above case the #stableVersion for Pharo1.0 might stay on the 3.0 branch even when the stableVersion moves on to 3.1 for other versions of Pharo.

Thinking back in the past ... I had versions of GemTools that were very sensitive to the version of OmniBrowser that was being used (in the old world using the package universe, that meant that all of a sudden the GemTools target would start loading a version of OmniBrowser that was incompatible...) which means that in some more obscure cases specific versions will still be used.

Dale

Mariano Martinez Peck wrote:

Hi dale. Finally I could read the email. I just agree :)

Now...if we can use stableVersion as a version in a project reference....I guess we will do that 99% of the times?  I mean, I am trying to think an sceario where using stableVersion is NOT what I wanat....but I don't find

cheers

Mariano

On Thu, Sep 30, 2010 at 10:28 PM, Dale Henrichs <[hidden email] <mailto:[hidden email]>> wrote:

   Tudor Girba wrote:

       Hi,

       Sorry for the late reply, but I was a bit swamped into other
       projects.

       I read the thread now, but I am not sure I understand how this would
       work for the bleedingEdge behavior.

       Will I have to write something like this?

       ConfigurationOfMoose>>bleedingEdgeVersion: spec <symbolicVersion:
       #bleedingEdge> spec for: #'common' version: 'default'.


   My expectations for bleedingEdge is that there will be combination of
   several things done:

    1. There will be a bleedingEdgeVersion method in the default
       ConfigurationOf template that looks something like the following
       (as suggested by Sean):

       bleedingEdgeVersion
       <symbolicVersion: #bleedingEdge>

       versions := self map values versions select: [ :version |
           '*baseline*' match: version name ].
       ^ baselines detectMax: [ :version | version ].

    2. There will be an optional method that may specify platform-specific
       bleedingEdge versions:

       bleedingEdgeVersion:spec
       <symbolicVersion: #bleedingEdge>

       spec for: #'pharo1.0.x' version: 'baseline-1.0'.
       spec for: #'pharo1.1.x' version: 'baseline-1.1'.

   Using the above as a example, the following expression would give
   different results based upon which version of Pharo the expression is
   evaluated in:

    (ConfigurationOfX project version: #bleedingEdge) load.

   On Pharo1.0, version 'baseline-1.0' would be loaded.
   On Pharo1.1, version 'baseline-1.1' would be loaded.
   On Pharo1.2 and beyond, the algorithm in step one would be applied.

   Sooo for Moose, the default #bleedingEdgeVersion is what you want
   and you'd not need to do anything special (i.e., no need to
   implement #.bleedingEdgeVersion:)



       I am not sure what this will bring for the "default" case. My
       goal is
       to load the latest version of packages present in the latest
       baseline
       :). Now, because there was no way to refer to such a behavior, we
       introduced "default" as the place that always shows the most recent
       baseline. Having the method as above is just another indirection to
       the "default".


   One of the reasons for allowing messages to be sent to resolve
   symbolicVersions is to provide for a way to specify this
   behavior...presumably you can move away from having 'default'
   versions in the future ... their use will be replaced by the
   #bleedingEdge version.



       Another point is that it looks to me like you will have only one
       pragma like <symbolicVersion: #stableVersion> for the entire
       configuration class. This would go against the "immutability" of
       descriptions, achieved until now. This immutability is nice because
       it enables you to create tools easily. Would it not be an idea to
       have this description in the actual version:
       ConfigurationOfX>>versionY: spec <stableVersion: 'Y'>


   The problem that we're trying to solve with symbolicVersions and the
   <symbolicVersion: #stableVersion> pragma is that a different version
   of the project is considered the #stableVersion depending upon the
   platform you are running on (Pharo1.0 vs Pharo1.2)....which implies
   three things:

    1. Multiple versions _will_ be tagged as a #stableVersion
    2. only one version can be the #stableVersion in a given instance
       (config plus platform ... config plus attributes)
    3. over time the versions _are_ immutable, while the #stableVersion
       _is_ expected to changed.

   So separating out the symbolicVersion specification in a separate
   method gives better visibility of which versions are associated with
   which symbolic version. It also reduces the likelihood that
   duplicate specifications will occur.



       How are these pragmas different from the blessing levels that
       already
       exists?


   SymbolicVersions are conditional and blessings are not ... the same
   problem that exists with the <stableVersion: 'Y'> pragma ... The
   important aspect is that the value is different depending upon which
   platform you are on...



       If you still want to go with the original design, why have a pragma
       when you should only have one pragma per class? I believe this can
       lead to confusions in which we have multiple methods specifying
       stable versions. Why not just a set of methods?


   I'm not sure that I understand what you are getting at here. It
   would be nice if we could get out a white board and talk this over
   face to face ...

   To summarize what I am thinking ...

   #stableVersion is an explicit declaration for the dynamic concept:
   "load the latest released version of the project for the platform
   that I'm running on"

   #bleedingEdgeVersion an explicit declaration for the dynamic
   concept: "load the latest baseline version."

   The real value for symbolicVersions is not only that someone can
   explicitly load the #stableVersion, but another project can specify
   the #stableVersion in it's project reference ... something that
   cannot be done at all today.

   I'm imagining that we will need to expand the symbolicVersion
   concept to include version-specific symbolicVersions:

    - #'3.0' defined as: "load the latest version of 3.0"
    - #'3.1' defined as: "load the latest version of 3.1"

   This type of distinction would have been necessary for Seaside2.8
   and Seaside2.9 where projects would have wanted to distinguish
   between stable versions of 2.8 and 2.9 independent of platform.

   Note that the spec for #'3.1' at the very beginning of development
   will probably be #bleedingEdgeVersion, however, once folks begin
   using 3.1 in production applications, the spec should be changed to
   #stableVersion until development of 3.2 begins and the cycle starts
   again. With the current proposal, it is possible to define #'3.0',
   #'3.1', #stableVersion, #bleedingEdgeVersion explicitly or
   algorithmically.

   The literalVersion is an explicit declaration for a bunch of code
   that is functionally equivalent. Version '3.1' is expected to have
   the same set of functionality no matter which platform you are
   working on.

   The symbolicVersion is an explicit declaration of intent. In the
   current version of Metacello the only way to express intent is via
   the shorthand load methods: #lastVersion and #latestVersion. Doru,
   your desire for the 'default' conventions was aimed at being able to
   explicitly declare the intention to "load the latest version of all
   packages/projects".

   I think it is important that with symbolicVersions that we not
   restrict the range of intent (as was done with #lastVersion and
   #latestVersion). Moving forward I expect that we will be refining
   and expanding intent.

   It is also important to separate intent from the literalVersion
   specification. Version '3.1' is version '3.1' regardless of intent.
   In fact I expect that the intent for 3.1 will change over time, but
   I never expect version the specification of literalVersion 3.1 to
   change over time.

   Blessings were an initial cut at intent. Currently there are 4
   useful blessings (in my experience):

    - #development
    - #broken
    - #baseline
    - none of the above (or #release)

   blessings aren't flexible enough to cover the range of intent that
   we are seeing now:

    - latest version that should be used on the version of Pharo that I'm
      loading the code into (#stableVersion)
    - latest version of every package/project for this project
      (#bleedingEdge)
    - latest minor version of the version 'X.0' (#'3.0')

   I claim that there are two different mechanisms that must be used in
   specifying intent:

    - explicit declaration of an explicit definition
    - explicit declaration of an algorithmic definition

   #bleedingEdge is the obvious example that requires an explicit
   declaration of an algorithmic definition. We can choose to hard-wire
   the knowledge of #bleedingEdge into Metacello or we can allow the
   user to define the algorithm as part of the ConfigurationOf. I think
   that it makes sense to allow the definition of the algorithm as part
   of the Configuration. Repeating the example used earler, here's how
   I would sugegest we specify the algorithmic definition:

       bleedingEdgeVersion
       <symbolicVersion: #bleedingEdge>

       versions := self map values versions select: [ :version |
           '*baseline*' match: version name ].
       ^ baselines detectMax: [ :version | version ].


   #stableVersion is the obvious example that requires an explicit
   declaration of an explicit definition. Here's how I would suggest we
   specify the explicit defintions for ConfigurationOfOmniBrowser (at
   the point in time not too long ago when the only option was to load
   the bleedingEdge for Pharo 1.2):

       stableVersion:spec
       <symbolicVersion: #stableVersion>

       spec for: #'pharo1.0.x' version: '1.1.4'.
       spec for: #'pharo1.1.x' version: '1.1.5'.
       spec for: #'pharo1.2.x' version: #bleedingEdgeVersion.

   Sooo, I assume that the case for having symbolicVersions and
   literalVersions is a solid one. I am open to discussions on
   alternatives to symbolicVersions, but let's be clear in the subject
   line that the thread is about alternatives to symbolicVersions....

   I'm clearly biased in favor of keeping the specification of
   symbolicVersions separate from the literalVersion specifications, so
   if you have a argument in favor of combining the specs, then again
   make a clear statement in the subject line.

   I do think that there is room for improvement in the specification
   of symbolicVersions and am interested in hearing alternate proposals
   with clear statements in the subject line.

   It's really too bad that we can't have face to face discussions at a
   white board ... I always have a difficult time keeping track of the
   multiple threads of conversations in emails ... at the whiteboard,
   you can always grab the marker out of my hand and make your point
   ... it's just not possible with emails ...

   Dale