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 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 |
> 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 |
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 |
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/ 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. |
On 8 sept. 2010, at 17:29, Mariano Martinez Peck wrote:
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 |
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." |
Free forum by Nabble | Edit this page |