blog post (version 3)
Locked
 
|
ripped out the gory stuff expanded content development cycle walkthrough
... still more writing to be done:). |
blog_9.html (37K) |
|
Dale
I will probably do a pass on the metacello chapter and I will include after some massages your text. Now I have two questions from a developer perspective should stable: spec be defined on ConfigurationOfOmniBrowser? I think so Now for bleeding edge I never have to define it since its logic is what I want Now from a process point of view when I have stable: <synbolicVersion: #stable> spec for: #pharo1.0.x' version: 1.1.3 spec for: #pharo1.0.x' version: 1.1.5 spec for: #pharo1.2.x' version: 1.2.3 -> saved in repository MetacelloRepositoryFor1.2 and Omnibrowser I just have to create a new version of this method stable: <synbolicVersion: #stable> spec for: #pharo1.0.x' version: 1.1.3 spec for: #pharo1.0.x' version: 1.1.5 spec for: #pharo1.2.x' version: 1.2.3 spec for: #pharo1.3.x' version: 1.2.9 and publish it in MetacelloRepositoryFor1.3 and Omnibrowser Is it correct? > ripped out the gory stuff expanded content development cycle walkthrough ... still more writing to be done:). > > <blog_9.html> |
Re: blog post (version 3)
|
|
Dale: I promise to read it tonight and give my feedback.
cheers mariano On Thu, Jan 13, 2011 at 9:46 AM, stephane ducasse <[hidden email]> wrote: Dale |
|
|
In reply to this post by stephane ducasse-2
On 01/13/2011 12:46 AM, stephane ducasse wrote:
> Dale > > I will probably do a pass on the metacello chapter and I will include after some massages your text. > Now I have two questions > > from a developer perspective > > should stable: spec be defined on ConfigurationOfOmniBrowser? > I think so Yes. Moving forward we should expect a stable: method to be defined in every configuration (that has released versions) so that #stable can be consistently used. > Now for bleeding edge I never have to define it since its logic is what I want for the bulk of projects the default for bleeding edge is completely adequate. Only under special circumstances would bleeding edge need to be defined in a configuration. > > Now from a process point of view when I have > > stable: > <synbolicVersion: #stable> > > spec for: #pharo1.0.x' version: 1.1.3 > spec for: #pharo1.0.x' version: 1.1.5 > spec for: #pharo1.2.x' version: 1.2.3 > > -> saved in repository > MetacelloRepositoryFor1.2 > and Omnibrowser > > I just have to create a new version of this method > > stable: > <synbolicVersion: #stable> > > spec for: #pharo1.0.x' version: 1.1.3 > spec for: #pharo1.0.x' version: 1.1.5 > spec for: #pharo1.2.x' version: 1.2.3 > spec for: #pharo1.3.x' version: 1.2.9 > and publish it in > > MetacelloRepositoryFor1.3 > and Omnibrowser > > Is it correct? Yes that is correct... Dale |
|
|
In reply to this post by Dale Henrichs
Dale,
El mié, 12-01-2011 a las 16:55 -0800, Dale Henrichs escribió: > ripped out the gory stuff expanded content development cycle walkthrough > ... still more writing to be done:). > much better, it clarifies a lot of things for me and I'm sure for others too. I think is better because doesn't mention old metacello often and focus on the new functionality mostly. The thing that definitively rocks is the walk through. I finally have a whole vision of the metacello process. Thanks. A couple of minor points: The first paragraph where you load the packages using an existing config can confuse readers. Maybe something like "When you are developing your project and are building your configuration for the first time, you already have the packages that conform it loaded and correctly running on your image. In this example, it is necessary to load a set of packages to simulate a image that will be used to build the first configuration of the project. We'll cheat here an use an existing configuration (ConfigurationOfGemTools) to download and install in our image all the packages and dependencies needed (just as we would have to do by hand if we were the maintainers of the package). So, pay not much attention to this step and only focus in the fact that after evaluating it, you'll have loaded in your image all the packages needed to build our example configuration". section: Create Initial Version remark that the versions generated are the ones currently loaded in the image and done automatically by the toolbox section: Testing In the section Save initial configuration you use http://www.example.com/GemToolsRepository' as repository, but in Testing section you use squeaksource: 'MetacelloRepository' it should be: url: 'http://www.example.com/GemToolsRepository'. And maybe note that they should use a clean image to really test that the configuration is working correctly section: release Last MetacelloToolBox copyConfiguration: ConfigurationOfGemToolsExample to: 'http://www.example.com/MetacelloRepository'. should be: MetacelloToolBox copyConfiguration: ConfigurationOfGemToolsExample to: 'http://www.squeaksource.com/MetacelloRepository'. Cheers -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx |
Re: blog post (version 3)
|
|
In reply to this post by Dale Henrichs
Hi dale, I read the post. Nice!
I have a couple of questions: - in the first example of #baseline10: you use versionString: #'bleedingEdge'; however, in our example, you defined 'stable', not bleedingEdge (it is defined later). I got it, but maybe it is confusing for others. - "New attributes have been added to Metacello for Pharo and Squeak to correspond to platform version numbers:" it would be nice that you show and how project attributes are defined. You can just put an example of a #project defining them. - "With the exception of the #bleedingEdge version (which has a pre-defined default defined), you will need to edit your configuration to add the #stable version information." and what happen with #development? - If I have a project A that refenreces to a project B, and I am not using the toolbox, and in A I don't specify ANY verison of B nor in the baseline nor in a version, when I load A, which version you will load of B ? #stable? #bleedingEdge? #development? or just a validation error? the validation can work, but anyway, if you didn't do it, you will need something at runtime... Cheers mariano On Thu, Jan 13, 2011 at 7:16 PM, Dale Henrichs <[hidden email]> wrote:
|
|
|
In reply to this post by Dale Henrichs
Ok I will add that when I will take your blog as input for the book
On Jan 13, 2011, at 7:16 PM, Dale Henrichs wrote: > On 01/13/2011 12:46 AM, stephane ducasse wrote: >> Dale >> >> I will probably do a pass on the metacello chapter and I will include after some massages your text. >> Now I have two questions >> >> from a developer perspective >> >> should stable: spec be defined on ConfigurationOfOmniBrowser? >> I think so > > Yes. Moving forward we should expect a stable: method to be defined in every configuration (that has released versions) so that #stable can be consistently used. > >> Now for bleeding edge I never have to define it since its logic is what I want > > for the bulk of projects the default for bleeding edge is completely adequate. Only under special circumstances would bleeding edge need to be defined in a configuration. > >> >> Now from a process point of view when I have >> >> stable: >> <synbolicVersion: #stable> >> >> spec for: #pharo1.0.x' version: 1.1.3 >> spec for: #pharo1.0.x' version: 1.1.5 >> spec for: #pharo1.2.x' version: 1.2.3 >> >> -> saved in repository >> MetacelloRepositoryFor1.2 >> and Omnibrowser >> >> I just have to create a new version of this method >> >> stable: >> <synbolicVersion: #stable> >> >> spec for: #pharo1.0.x' version: 1.1.3 >> spec for: #pharo1.0.x' version: 1.1.5 >> spec for: #pharo1.2.x' version: 1.2.3 >> spec for: #pharo1.3.x' version: 1.2.9 >> and publish it in >> >> MetacelloRepositoryFor1.3 >> and Omnibrowser >> >> Is it correct? > > Yes that is correct... > > Dale > |
|
|
In reply to this post by Miguel Cobá
Migueal,
Excellent feedback, thanks...I've integerated your suggestions. More content coming and probably a little more reorganization as I explore the practical side:) Dale On 01/13/2011 10:41 AM, Miguel Cobá wrote: > Dale, > > El mié, 12-01-2011 a las 16:55 -0800, Dale Henrichs escribió: >> ripped out the gory stuff expanded content development cycle walkthrough >> ... still more writing to be done:). >> > > much better, it clarifies a lot of things for me and I'm sure for others > too. I think is better because doesn't mention old metacello often and > focus on the new functionality mostly. > The thing that definitively rocks is the walk through. I finally have a > whole vision of the metacello process. Thanks. A couple of minor points: > > The first paragraph where you load the packages using an existing config > can confuse readers. Maybe something like > > "When you are developing your project and are building your > configuration for the first time, you already have the packages that > conform it loaded and correctly running on your image. In this example, > it is necessary to load a set of packages to simulate a image that will > be used to build the first configuration of the project. We'll cheat > here an use an existing configuration (ConfigurationOfGemTools) to > download and install in our image all the packages and dependencies > needed (just as we would have to do by hand if we were the maintainers > of the package). So, pay not much attention to this step and only focus > in the fact that after evaluating it, you'll have loaded in your image > all the packages needed to build our example configuration". > > section: Create Initial Version > > remark that the versions generated are the ones currently loaded in the > image and done automatically by the toolbox > > section: Testing > > In the section Save initial configuration you use > http://www.example.com/GemToolsRepository' as repository, but in Testing > section you use > > squeaksource: 'MetacelloRepository' > > it should be: > > url: 'http://www.example.com/GemToolsRepository'. > > And maybe note that they should use a clean image to really test that > the configuration is working correctly > > section: release > > Last > > MetacelloToolBox > copyConfiguration: ConfigurationOfGemToolsExample > to: 'http://www.example.com/MetacelloRepository'. > > should be: > > MetacelloToolBox > copyConfiguration: ConfigurationOfGemToolsExample > to: 'http://www.squeaksource.com/MetacelloRepository'. > > > > Cheers > > |
|
|
In reply to this post by Mariano Martinez Peck
Mariano,
Excellent feedback, thanks...I've integrated your suggestions... If no version is specified in the baseline or literal version then the default is to use latestVersion and then #bleedingEdge. The validator flags this condition as a Critical Warning. After 1.0 I expect that this should be an error, but until then I think we need to preserve the current behavior and give folks to convert to using #stable which is the preferred default. In a baseline the decision between #stable and #baseline should be made on the following basis: - no #stable version exists, then use #bleedingEdge - #stable version exists, then use #stable - #stable version exists, but the project being referenced is logically part of the same project (like Grease and Seaside30) then use #bleedingEdge. - for versions like the 'default' version in Moose, #bleedingEdge should be used for the projects that define a corresponding 'default' version Dale On 01/13/2011 10:44 AM, Mariano Martinez Peck wrote: > Hi dale, I read the post. Nice! > > I have a couple of questions: > > - in the first example of #baseline10: > you use versionString: #'bleedingEdge'; > however, in our example, you defined 'stable', not bleedingEdge (it is > defined later). I got it, but maybe it is confusing for others. > > - "New attributes have been added to Metacello for Pharo and Squeak to > correspond to platform version numbers:" > it would be nice that you show and how project attributes are defined. > You can just put an example of a #project defining them. > > - "With the exception of the #bleedingEdge version (which has a > pre-defined default defined), you will need to edit your configuration > to add the #stable version information." > and what happen with #development? > > - If I have a project A that refenreces to a project B, and I am not > using the toolbox, and in A I don't specify ANY verison of B nor in the > baseline nor in a version, when I load A, which version you will load > of B ? #stable? #bleedingEdge? #development? or just a validation > error? the validation can work, but anyway, if you didn't do it, you > will need something at runtime... > > > Cheers > > mariano > > On Thu, Jan 13, 2011 at 7:16 PM, Dale Henrichs <[hidden email] > <mailto:[hidden email]>> wrote: > > On 01/13/2011 12:46 AM, stephane ducasse wrote: > > Dale > > I will probably do a pass on the metacello chapter and I will > include after some massages your text. > Now I have two questions > > from a developer perspective > > should stable: spec be defined on ConfigurationOfOmniBrowser? > I think so > > > Yes. Moving forward we should expect a stable: method to be defined > in every configuration (that has released versions) so that #stable > can be consistently used. > > > Now for bleeding edge I never have to define it since its logic > is what I want > > > for the bulk of projects the default for bleeding edge is completely > adequate. Only under special circumstances would bleeding edge need > to be defined in a configuration. > > > > Now from a process point of view when I have > > stable: > <synbolicVersion: #stable> > > spec for: #pharo1.0.x' version: 1.1.3 > spec for: #pharo1.0.x' version: 1.1.5 > spec for: #pharo1.2.x' version: 1.2.3 > > -> saved in repository > MetacelloRepositoryFor1.2 > and Omnibrowser > > I just have to create a new version of this method > > stable: > <synbolicVersion: #stable> > > spec for: #pharo1.0.x' version: 1.1.3 > spec for: #pharo1.0.x' version: 1.1.5 > spec for: #pharo1.2.x' version: 1.2.3 > spec for: #pharo1.3.x' version: 1.2.9 > and publish it in > > MetacelloRepositoryFor1.3 > and Omnibrowser > > Is it correct? > > > Yes that is correct... > > Dale > > |
Re: blog post (version 3)
|
|
On Thu, Jan 13, 2011 at 10:01 PM, Dale Henrichs <[hidden email]> wrote: Mariano, I don't understand the "then". I mean, you can always get the latestVersion. So...what you refer by "then" ? in which case it will use #bleedingEdge ? The validator flags this condition as a Critical Warning. After 1.0 I expect that this should be an error, but until then I think we need to preserve the current behavior and give folks to convert to using #stable which is the preferred default. Thanks for the explanation Dale mariano
|
|
|
On 01/13/2011 01:11 PM, Mariano Martinez Peck wrote:
> > > On Thu, Jan 13, 2011 at 10:01 PM, Dale Henrichs <[hidden email] > <mailto:[hidden email]>> wrote: > > Mariano, > > Excellent feedback, thanks...I've integrated your suggestions... > > If no version is specified in the baseline or literal version then > the default is to use latestVersion and then #bleedingEdge. > > > I don't understand the "then". I mean, you can always get the > latestVersion. So...what you refer by "then" ? in which case it will use > #bleedingEdge ? There are certain condition under which #latestVersion fails to find a version (all version blessings are #baseline or development)... If there is no #bleedingEdge version, then an error is thrown. > > The validator flags this condition as a Critical Warning. After 1.0 > I expect that this should be an error, but until then I think we > need to preserve the current behavior and give folks to convert to > using #stable which is the preferred default. > > In a baseline the decision between #stable and #baseline should be > made on the following basis: > > - no #stable version exists, then use #bleedingEdge > - #stable version exists, then use #stable > - #stable version exists, but the project being referenced is > logically part of the same project (like Grease and Seaside30) > then use #bleedingEdge. > - for versions like the 'default' version in Moose, #bleedingEdge > should be used for the projects that define a corresponding > 'default' version > > > Thanks for the explanation Dale > > mariano > > > Dale > > > On 01/13/2011 10:44 AM, Mariano Martinez Peck wrote: > > Hi dale, I read the post. Nice! > > I have a couple of questions: > > - in the first example of #baseline10: > you use versionString: #'bleedingEdge'; > however, in our example, you defined 'stable', not bleedingEdge > (it is > defined later). I got it, but maybe it is confusing for others. > > - "New attributes have been added to Metacello for Pharo and > Squeak to > correspond to platform version numbers:" > it would be nice that you show and how project attributes are > defined. > You can just put an example of a #project defining them. > > - "With the exception of the #bleedingEdge version (which has a > pre-defined default defined), you will need to edit your > configuration > to add the #stable version information." > and what happen with #development? > > - If I have a project A that refenreces to a project B, and I am not > using the toolbox, and in A I don't specify ANY verison of B > nor in the > baseline nor in a version, when I load A, which version you > will load > of B ? #stable? #bleedingEdge? #development? or just a validation > error? the validation can work, but anyway, if you didn't do > it, you > will need something at runtime... > > > Cheers > > mariano > > On Thu, Jan 13, 2011 at 7:16 PM, Dale Henrichs > <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> wrote: > > On 01/13/2011 12:46 AM, stephane ducasse wrote: > > Dale > > I will probably do a pass on the metacello chapter and I > will > include after some massages your text. > Now I have two questions > > from a developer perspective > > should stable: spec be defined on > ConfigurationOfOmniBrowser? > I think so > > > Yes. Moving forward we should expect a stable: method to be > defined > in every configuration (that has released versions) so that > #stable > can be consistently used. > > > Now for bleeding edge I never have to define it since > its logic > is what I want > > > for the bulk of projects the default for bleeding edge is > completely > adequate. Only under special circumstances would bleeding > edge need > to be defined in a configuration. > > > > Now from a process point of view when I have > > stable: > <synbolicVersion: #stable> > > spec for: #pharo1.0.x' version: 1.1.3 > spec for: #pharo1.0.x' version: 1.1.5 > spec for: #pharo1.2.x' version: 1.2.3 > > -> saved in repository > MetacelloRepositoryFor1.2 > and Omnibrowser > > I just have to create a new version of this method > > stable: > <synbolicVersion: #stable> > > spec for: #pharo1.0.x' version: 1.1.3 > spec for: #pharo1.0.x' version: 1.1.5 > spec for: #pharo1.2.x' version: 1.2.3 > spec for: #pharo1.3.x' version: 1.2.9 > and publish it in > > MetacelloRepositoryFor1.3 > and Omnibrowser > > Is it correct? > > > Yes that is correct... > > Dale > > > > |
Re: blog post (version 3)
|
|
On Thu, Jan 13, 2011 at 10:26 PM, Dale Henrichs <[hidden email]> wrote:
aaaahh ;) If there is no #bleedingEdge version, then an error is thrown. |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |