[[last | latest | stable]Version | bleedingEdge]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[[last | latest | stable]Version | bleedingEdge]

Sean DeNigris
I wasn't sure if commenting on a closed issue (http://code.google.com/
p/metacello/issues/detail?id=94) would be seen, so I'm posting my
comment here.

After playing with this, it seems that there are 3 options:
1. load the latest stable version based on the blessing -
#stableVersion
2. load the latest version, regardless of blessing -> #bleedingEdge
3. load the latest version of each package, regardless of whether
there's a version method mentioning them -> (ConfigurationOfXxx
project version: 'x.x-baseline') load

Is that correct?  And, is #2 really the "bleeding edge," or is #3?
I'm unclear on the difference in use case for #2 and #3.

Thanks.
Sean
Reply | Threaded
Open this post in threaded view
|

Re: [[last | latest | stable]Version | bleedingEdge]

Dale Henrichs
Sean DeNigris wrote:

> I wasn't sure if commenting on a closed issue (http://code.google.com/
> p/metacello/issues/detail?id=94) would be seen, so I'm posting my
> comment here.
>
> After playing with this, it seems that there are 3 options:
> 1. load the latest stable version based on the blessing -
> #stableVersion
> 2. load the latest version, regardless of blessing -> #bleedingEdge
> 3. load the latest version of each package, regardless of whether
> there's a version method mentioning them -> (ConfigurationOfXxx
> project version: 'x.x-baseline') load
>
> Is that correct?  And, is #2 really the "bleeding edge," or is #3?
> I'm unclear on the difference in use case for #2 and #3.
>
> Thanks.
> Sean

Sean,

Good points ... #3 sort of ties in with Doru's interest in a 'default'
version...from a loading perspective ...

I suppose now that we talk about it ...

   1. #stableVersion     - latest non-development release
   2. #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)
   3. #bleedingEdge      - latest version of every package/project -
                           uses the mechanism that we decide to use for
                           naming the 'default' version

Is this a clearer set of use cases?

Dale
Reply | Threaded
Open this post in threaded view
|

Re: [[last | latest | stable]Version | bleedingEdge]

stephane ducasse-2
> Good points ... #3 sort of ties in with Doru's interest in a 'default' version...from a loading perspective ...
>
> I suppose now that we talk about it ...
>
>  1. #stableVersion     - latest non-development release

        what happens is there is no version for a package?
        I hope that this is an error because for my case I want always to load specific version.

>  2. #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)
>  3. #bleedingEdge      - latest version of every package/project -
>                          uses the mechanism that we decide to use for
>                          naming the 'default' version
>
> Is this a clearer set of use cases?
>
> Dale

Reply | Threaded
Open this post in threaded view
|

Re: [[last | latest | stable]Version | bleedingEdge]

Simon Denier-3
In reply to this post by Dale Henrichs

On 8 sept. 2010, at 01:44, Dale Henrichs wrote:

> Sean DeNigris wrote:
>> I wasn't sure if commenting on a closed issue (http://code.google.com/
>> p/metacello/issues/detail?id=94) would be seen, so I'm posting my
>> comment here.
>> After playing with this, it seems that there are 3 options:
>> 1. load the latest stable version based on the blessing -
>> #stableVersion
>> 2. load the latest version, regardless of blessing -> #bleedingEdge
>> 3. load the latest version of each package, regardless of whether
>> there's a version method mentioning them -> (ConfigurationOfXxx
>> project version: 'x.x-baseline') load
>> Is that correct?  And, is #2 really the "bleeding edge," or is #3?
>> I'm unclear on the difference in use case for #2 and #3.
>> Thanks.
>> Sean
>
> Sean,
>
> Good points ... #3 sort of ties in with Doru's interest in a 'default' version...from a loading perspective ...
>
> I suppose now that we talk about it ...
>
>  1. #stableVersion     - latest non-development release
>  2. #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)
>  3. #bleedingEdge      - latest version of every package/project -
>                          uses the mechanism that we decide to use for
>                          naming the 'default' version
>
> Is this a clearer set of use cases?



Yes! I like this proposal.


--
 Simon



Reply | Threaded
Open this post in threaded view
|

Re: [[last | latest | stable]Version | bleedingEdge]

Mariano Martinez Peck
In reply to this post by Sean DeNigris


On Wed, Sep 8, 2010 at 1:22 AM, Sean DeNigris <[hidden email]> wrote:
I wasn't sure if commenting on a closed issue (http://code.google.com/
p/metacello/issues/detail?id=94
) would be seen, so I'm posting my
comment here.

After playing with this, it seems that there are 3 options:
1. load the latest stable version based on the blessing -
#stableVersion
2. load the latest version, regardless of blessing -> #bleedingEdge
3. load the latest version of each package, regardless of whether
there's a version method mentioning them -> (ConfigurationOfXxx
project version: 'x.x-baseline') load

Is that correct?  And, is #2 really the "bleeding edge," or is #3?


Monticello is like CVS. You can commit whatever you want. Things that doesn't work, that are incomplete, etc.
This is why there is a difference between 2) and 3). You can define a group of versions that should "more or less" work, althought the project is still in development.

For example, I can be developing SqueakDBX 1.2. I can a version 1.2 as development, buy tag versions that are working, altoguh this is not complete for the 1.2 release. People can see my progress by downloading them.

On the other hand, mostly for internal SqueakDBX developers, you may want to download the LATEST version of all package. This is like everything. Before starting to work on something, you first do an update ;)

this make sense?  I ask because this is the way I work. Maybe for example in Moose they do somehting different. They only commit to monticello when everything is working, then 2) and 3) may be similar, and they prefer to use 3)

cheers

mariano

 
I'm unclear on the difference in use case for #2 and #3.

Thanks.
Sean

Reply | Threaded
Open this post in threaded view
|

Re: [[last | latest | stable]Version | bleedingEdge]

Simon Denier-3

On 8 sept. 2010, at 17:29, Mariano Martinez Peck wrote:



On Wed, Sep 8, 2010 at 1:22 AM, Sean DeNigris <[hidden email]> wrote:
I wasn't sure if commenting on a closed issue (http://code.google.com/
p/metacello/issues/detail?id=94
) would be seen, so I'm posting my
comment here.

After playing with this, it seems that there are 3 options:
1. load the latest stable version based on the blessing -
#stableVersion
2. load the latest version, regardless of blessing -> #bleedingEdge
3. load the latest version of each package, regardless of whether
there's a version method mentioning them -> (ConfigurationOfXxx
project version: 'x.x-baseline') load

Is that correct?  And, is #2 really the "bleeding edge," or is #3?




On the other hand, mostly for internal SqueakDBX developers, you may want to download the LATEST version of all package. This is like everything. Before starting to work on something, you first do an update ;)

this make sense?  I ask because this is the way I work. Maybe for example in Moose they do somehting different. They only commit to monticello when everything is working, then 2) and 3) may be similar, and they prefer to use 3)


No no, in Moose we use 1) and 3) :)

There was plenty of discussion to do 2), (which resulted in some Metacello patches, thanks Dale!), but it was considered too costly to make a release for development versions (Moose uses multiples projects, so 1 release involves releasing all those projects).


--
 Simon



Reply | Threaded
Open this post in threaded view
|

Re: [[last | latest | stable]Version | bleedingEdge]

Sean DeNigris
In reply to this post by Dale Henrichs
On Sep 7, 7:44 pm, Dale Henrichs <[hidden email]> wrote:
>    1. #stableVersion     - latest non-development release
Okay, so we have that with the present fix

>    2. #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)
So what is #bleedingEdge in the fix would be #development

>    3. #bleedingEdge      - latest version of every package/project -
>                            uses the mechanism that we decide to use for
>                            naming the 'default' version
#bleedingEdge would be something like:
MetacelloProject>>bleedingEdge

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

Which would be equivalent to the API's advice @
http://code.google.com/p/metacello/wiki/FAQ#How_do_I_load_the_last_version_of_a_project?:
  (ConfigurationOfCAnalyzer project version: '1.0-baseline') load

which would become part of the API as:
  "ConfigurationOfCAnalyzer project bleedingEdge load."