default convention

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

default convention

Tudor Girba
Hi,

I would like to propose the convention of a default baseline in every  
configuration. This is particularly useful from a development point of  
view. We use this in all Moose projects with success.

The scenario is like this:
- default is a baseline (i.e., without explicit versions)
- it represents the current development configuration
- that means that we only work on the default
- every time we want to create an explicit version, we copy default to  
a corresponding baseline and we create the version

The benefit of this convention is that it provides a simple way to  
depend on a configuration for development without needing to update  
for every new version.

For example, now we have ConfigurationOfGlamourSeaside and we want to  
depend on ConfigurationOfSeaside. In the current form, we can only  
depend on version "3.0.0-alpha5.15". However, for development purposes  
we would need access to the latest fixes which are not yet in a  
version. If there would be a default, we could just have our default  
depend on that one.

What do you think?

Cheers,
Doru

--
www.tudorgirba.com

"No matter how many recipes we know, we still value a chef."






Reply | Threaded
Open this post in threaded view
|

Re: default convention

Hernan Wilkinson-3
I like the idea but the word "default" does not mean to much to me on this context... I think we could use another word like "baseline" or "current" (I like baseline more...), don't you thinnk?

On Fri, Aug 6, 2010 at 5:11 PM, Tudor Girba <[hidden email]> wrote:
Hi,

I would like to propose the convention of a default baseline in every configuration. This is particularly useful from a development point of view. We use this in all Moose projects with success.

The scenario is like this:
- default is a baseline (i.e., without explicit versions)
- it represents the current development configuration
- that means that we only work on the default
- every time we want to create an explicit version, we copy default to a corresponding baseline and we create the version

The benefit of this convention is that it provides a simple way to depend on a configuration for development without needing to update for every new version.

For example, now we have ConfigurationOfGlamourSeaside and we want to depend on ConfigurationOfSeaside. In the current form, we can only depend on version "3.0.0-alpha5.15". However, for development purposes we would need access to the latest fixes which are not yet in a version. If there would be a default, we could just have our default depend on that one.

What do you think?

Cheers,
Doru

--
www.tudorgirba.com

"No matter how many recipes we know, we still value a chef."









--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 11 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com

Reply | Threaded
Open this post in threaded view
|

Re: default convention

stephane ducasse-2
In reply to this post by Tudor Girba
i know you like default :)
Now I would ban it (with an explicit configuration checker) from published version else we can end up in situation were we can only load the latest version.

Stef
On Aug 6, 2010, at 10:11 PM, Tudor Girba wrote:

> Hi,
>
> I would like to propose the convention of a default baseline in every configuration. This is particularly useful from a development point of view. We use this in all Moose projects with success.
>
> The scenario is like this:
> - default is a baseline (i.e., without explicit versions)
> - it represents the current development configuration
> - that means that we only work on the default
> - every time we want to create an explicit version, we copy default to a corresponding baseline and we create the version
>
> The benefit of this convention is that it provides a simple way to depend on a configuration for development without needing to update for every new version.
>
> For example, now we have ConfigurationOfGlamourSeaside and we want to depend on ConfigurationOfSeaside. In the current form, we can only depend on version "3.0.0-alpha5.15". However, for development purposes we would need access to the latest fixes which are not yet in a version. If there would be a default, we could just have our default depend on that one.
>
> What do you think?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "No matter how many recipes we know, we still value a chef."
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: default convention

Tudor Girba
In reply to this post by Hernan Wilkinson-3
default comes from "default configuration".

It is the default place you look at if nothing else is there, the  
default place you change, and the default version you want to load by  
default :).

Cheers,
Doru

On 6 Aug 2010, at 23:25, Hernan Wilkinson wrote:

> I like the idea but the word "default" does not mean to much to me  
> on this context... I think we could use another word like "baseline"  
> or "current" (I like baseline more...), don't you thinnk?
>
> On Fri, Aug 6, 2010 at 5:11 PM, Tudor Girba <[hidden email]>  
> wrote:
> Hi,
>
> I would like to propose the convention of a default baseline in  
> every configuration. This is particularly useful from a development  
> point of view. We use this in all Moose projects with success.
>
> The scenario is like this:
> - default is a baseline (i.e., without explicit versions)
> - it represents the current development configuration
> - that means that we only work on the default
> - every time we want to create an explicit version, we copy default  
> to a corresponding baseline and we create the version
>
> The benefit of this convention is that it provides a simple way to  
> depend on a configuration for development without needing to update  
> for every new version.
>
> For example, now we have ConfigurationOfGlamourSeaside and we want  
> to depend on ConfigurationOfSeaside. In the current form, we can  
> only depend on version "3.0.0-alpha5.15". However, for development  
> purposes we would need access to the latest fixes which are not yet  
> in a version. If there would be a default, we could just have our  
> default depend on that one.
>
> What do you think?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "No matter how many recipes we know, we still value a chef."
>
>
>
>
>
>
>
>
>
> --
> Hernán Wilkinson
> Agile Software Development, Teaching & Coaching
> Mobile: +54 - 11 - 4470 - 7207
> email: [hidden email]
> site: http://www.10Pines.com
>

--
www.tudorgirba.com

"We cannot reach the flow of things unless we let go."



Reply | Threaded
Open this post in threaded view
|

Re: default convention

Tudor Girba
In reply to this post by stephane ducasse-2
That is a good idea.

Cheers,
Doru


On 6 Aug 2010, at 23:36, stephane ducasse wrote:

> i know you like default :)
> Now I would ban it (with an explicit configuration checker) from  
> published version else we can end up in situation were we can only  
> load the latest version.
>
> Stef
> On Aug 6, 2010, at 10:11 PM, Tudor Girba wrote:
>
>> Hi,
>>
>> I would like to propose the convention of a default baseline in  
>> every configuration. This is particularly useful from a development  
>> point of view. We use this in all Moose projects with success.
>>
>> The scenario is like this:
>> - default is a baseline (i.e., without explicit versions)
>> - it represents the current development configuration
>> - that means that we only work on the default
>> - every time we want to create an explicit version, we copy default  
>> to a corresponding baseline and we create the version
>>
>> The benefit of this convention is that it provides a simple way to  
>> depend on a configuration for development without needing to update  
>> for every new version.
>>
>> For example, now we have ConfigurationOfGlamourSeaside and we want  
>> to depend on ConfigurationOfSeaside. In the current form, we can  
>> only depend on version "3.0.0-alpha5.15". However, for development  
>> purposes we would need access to the latest fixes which are not yet  
>> in a version. If there would be a default, we could just have our  
>> default depend on that one.
>>
>> What do you think?
>>
>> Cheers,
>> Doru
>>
>> --
>> www.tudorgirba.com
>>
>> "No matter how many recipes we know, we still value a chef."
>>
>>
>>
>>
>>
>>
>

--
www.tudorgirba.com

"Every now and then stop and ask yourself if the war you're fighting  
is the right one."



Reply | Threaded
Open this post in threaded view
|

Re: default convention

Hernan Wilkinson-3
In reply to this post by Tudor Girba
I still don't like the "defulat" word for this :-)

On Fri, Aug 6, 2010 at 6:45 PM, Tudor Girba <[hidden email]> wrote:
default comes from "default configuration".

It is the default place you look at if nothing else is there, the default place you change, and the default version you want to load by default :).

Cheers,
Doru


On 6 Aug 2010, at 23:25, Hernan Wilkinson wrote:

I like the idea but the word "default" does not mean to much to me on this context... I think we could use another word like "baseline" or "current" (I like baseline more...), don't you thinnk?

On Fri, Aug 6, 2010 at 5:11 PM, Tudor Girba <[hidden email]> wrote:
Hi,

I would like to propose the convention of a default baseline in every configuration. This is particularly useful from a development point of view. We use this in all Moose projects with success.

The scenario is like this:
- default is a baseline (i.e., without explicit versions)
- it represents the current development configuration
- that means that we only work on the default
- every time we want to create an explicit version, we copy default to a corresponding baseline and we create the version

The benefit of this convention is that it provides a simple way to depend on a configuration for development without needing to update for every new version.

For example, now we have ConfigurationOfGlamourSeaside and we want to depend on ConfigurationOfSeaside. In the current form, we can only depend on version "3.0.0-alpha5.15". However, for development purposes we would need access to the latest fixes which are not yet in a version. If there would be a default, we could just have our default depend on that one.

What do you think?

Cheers,
Doru

--
www.tudorgirba.com

"No matter how many recipes we know, we still value a chef."









--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 11 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com


--
www.tudorgirba.com

"We cannot reach the flow of things unless we let go."






--
Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 11 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com

Reply | Threaded
Open this post in threaded view
|

Re: default convention

Dale Henrichs
In reply to this post by Tudor Girba
Tudor,

I've been mulling this one over a bit and I think I'd like to suggest an
alternate approach that is a little more general and can be applied in a
few more use cases....

We are talking about project references and I've been bothered for
awhile about the fact that when specifying a project reference, you have
two choices (don't specify a version and you'll always get the
#latestVersion) or specify an explicit version ... the #latestVersion is
not bad, but it doesn't address the fact the #baselines should be
treated differently. The explicit version isn't real useful when you are
specifying a baseline .... too restrictive.

Soo, I think that I'd like to extend the way that versions can be
specified to include a "dynamic version spec".

The idea is that you can specify a symbol as a _project_ version string:

   - '#latestVersion' is equivalent to the current no specification
   - '#lastVersion' allows for pulling in the #lastVersion of a project
   - '#lastBaseline' for pulling in the latest #baseline version

These specifications can be used from within a baseline or a version
spec, but only for project specs. Note that you can use a Symbol or a
String for the spec (i.e., '#latestVersion' and #latestVersion should work).

I also propose adding a corresponding #lastBaseline to MetacelloProject.

If I'm not mistaken, this will satisfy your requirement for referencing
other projects, since I believe that in your case the meaning of
"current development configuration" is the latest version of everything...

A convention isn't a bad idea, but we need an answer for configurations
that don't follow the convention (or whose definition of default is not
really what one wants)...

I can imagine a situation where I would use #latestBaseline and
#latestVersion for project specs in the latest baseline and latest
version of a configuration, but when I find it necessary to create a new
baseline or version, I would be inclined to replace the #latestBaseline
and #latestVersion specs with the actual baseline and version, so that
the spec would be locked down from that point forward ...

Dale

Tudor Girba wrote:

> Hi,
>
> I would like to propose the convention of a default baseline in every  
> configuration. This is particularly useful from a development point of  
> view. We use this in all Moose projects with success.
>
> The scenario is like this:
> - default is a baseline (i.e., without explicit versions)
> - it represents the current development configuration
> - that means that we only work on the default
> - every time we want to create an explicit version, we copy default to  
> a corresponding baseline and we create the version
>
> The benefit of this convention is that it provides a simple way to  
> depend on a configuration for development without needing to update  
> for every new version.
>
> For example, now we have ConfigurationOfGlamourSeaside and we want to  
> depend on ConfigurationOfSeaside. In the current form, we can only  
> depend on version "3.0.0-alpha5.15". However, for development purposes  
> we would need access to the latest fixes which are not yet in a  
> version. If there would be a default, we could just have our default  
> depend on that one.
>
> What do you think?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "No matter how many recipes we know, we still value a chef."
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: default convention

Tudor Girba
Hi Dale,

Sorry for the late reply. I somehow lost track of this thread :(.

The problem is that baseline is still a naming convention. So, for  
example, if I have #default as a baseline, and #aProject-baseline.xxx  
as the baselines, #default will always be the lastBaseline.

Perhaps we could introduce an explicit pragma to distinguish between  
versions, baselines and "current"?

Cheers,
Doru


On 9 Aug 2010, at 21:15, Dale Henrichs wrote:

> Tudor,
>
> I've been mulling this one over a bit and I think I'd like to  
> suggest an alternate approach that is a little more general and can  
> be applied in a few more use cases....
>
> We are talking about project references and I've been bothered for  
> awhile about the fact that when specifying a project reference, you  
> have two choices (don't specify a version and you'll always get the  
> #latestVersion) or specify an explicit version ... the  
> #latestVersion is not bad, but it doesn't address the fact the  
> #baselines should be treated differently. The explicit version isn't  
> real useful when you are specifying a baseline .... too restrictive.
>
> Soo, I think that I'd like to extend the way that versions can be  
> specified to include a "dynamic version spec".
>
> The idea is that you can specify a symbol as a _project_ version  
> string:
>
>  - '#latestVersion' is equivalent to the current no specification
>  - '#lastVersion' allows for pulling in the #lastVersion of a project
>  - '#lastBaseline' for pulling in the latest #baseline version
>
> These specifications can be used from within a baseline or a version  
> spec, but only for project specs. Note that you can use a Symbol or  
> a String for the spec (i.e., '#latestVersion' and #latestVersion  
> should work).
>
> I also propose adding a corresponding #lastBaseline to  
> MetacelloProject.
>
> If I'm not mistaken, this will satisfy your requirement for  
> referencing other projects, since I believe that in your case the  
> meaning of "current development configuration" is the latest version  
> of everything...
>
> A convention isn't a bad idea, but we need an answer for  
> configurations that don't follow the convention (or whose definition  
> of default is not really what one wants)...
>
> I can imagine a situation where I would use #latestBaseline and  
> #latestVersion for project specs in the latest baseline and latest  
> version of a configuration, but when I find it necessary to create a  
> new baseline or version, I would be inclined to replace the  
> #latestBaseline and #latestVersion specs with the actual baseline  
> and version, so that the spec would be locked down from that point  
> forward ...
>
> Dale
>
> Tudor Girba wrote:
>> Hi,
>> I would like to propose the convention of a default baseline in  
>> every  configuration. This is particularly useful from a  
>> development point of  view. We use this in all Moose projects with  
>> success.
>> The scenario is like this:
>> - default is a baseline (i.e., without explicit versions)
>> - it represents the current development configuration
>> - that means that we only work on the default
>> - every time we want to create an explicit version, we copy default  
>> to  a corresponding baseline and we create the version
>> The benefit of this convention is that it provides a simple way to  
>> depend on a configuration for development without needing to  
>> update  for every new version.
>> For example, now we have ConfigurationOfGlamourSeaside and we want  
>> to  depend on ConfigurationOfSeaside. In the current form, we can  
>> only  depend on version "3.0.0-alpha5.15". However, for development  
>> purposes  we would need access to the latest fixes which are not  
>> yet in a  version. If there would be a default, we could just have  
>> our default  depend on that one.
>> What do you think?
>> Cheers,
>> Doru
>> --
>> www.tudorgirba.com
>> "No matter how many recipes we know, we still value a chef."
>

--
www.tudorgirba.com

"Live like you mean it."

Reply | Threaded
Open this post in threaded view
|

Re: default convention

Dale Henrichs
Doru,

Now I'm sorry that I lost the thread, too...

Let me think on your suggestion a bit ... I agree that my suggestion
doesn't solve your problem and I like the idea of an explicit pragma
better than naming ... I think ...

just a thought ... would #current as a blessing: fill the bill?

Dale

Tudor Girba wrote:

> Hi Dale,
>
> Sorry for the late reply. I somehow lost track of this thread :(.
>
> The problem is that baseline is still a naming convention. So, for  
> example, if I have #default as a baseline, and #aProject-baseline.xxx  
> as the baselines, #default will always be the lastBaseline.
>
> Perhaps we could introduce an explicit pragma to distinguish between  
> versions, baselines and "current"?
>
> Cheers,
> Doru
>
>
> On 9 Aug 2010, at 21:15, Dale Henrichs wrote:
>
>> Tudor,
>>
>> I've been mulling this one over a bit and I think I'd like to  
>> suggest an alternate approach that is a little more general and can  
>> be applied in a few more use cases....
>>
>> We are talking about project references and I've been bothered for  
>> awhile about the fact that when specifying a project reference, you  
>> have two choices (don't specify a version and you'll always get the  
>> #latestVersion) or specify an explicit version ... the  
>> #latestVersion is not bad, but it doesn't address the fact the  
>> #baselines should be treated differently. The explicit version isn't  
>> real useful when you are specifying a baseline .... too restrictive.
>>
>> Soo, I think that I'd like to extend the way that versions can be  
>> specified to include a "dynamic version spec".
>>
>> The idea is that you can specify a symbol as a _project_ version  
>> string:
>>
>>  - '#latestVersion' is equivalent to the current no specification
>>  - '#lastVersion' allows for pulling in the #lastVersion of a project
>>  - '#lastBaseline' for pulling in the latest #baseline version
>>
>> These specifications can be used from within a baseline or a version  
>> spec, but only for project specs. Note that you can use a Symbol or  
>> a String for the spec (i.e., '#latestVersion' and #latestVersion  
>> should work).
>>
>> I also propose adding a corresponding #lastBaseline to  
>> MetacelloProject.
>>
>> If I'm not mistaken, this will satisfy your requirement for  
>> referencing other projects, since I believe that in your case the  
>> meaning of "current development configuration" is the latest version  
>> of everything...
>>
>> A convention isn't a bad idea, but we need an answer for  
>> configurations that don't follow the convention (or whose definition  
>> of default is not really what one wants)...
>>
>> I can imagine a situation where I would use #latestBaseline and  
>> #latestVersion for project specs in the latest baseline and latest  
>> version of a configuration, but when I find it necessary to create a  
>> new baseline or version, I would be inclined to replace the  
>> #latestBaseline and #latestVersion specs with the actual baseline  
>> and version, so that the spec would be locked down from that point  
>> forward ...
>>
>> Dale
>>
>> Tudor Girba wrote:
>>> Hi,
>>> I would like to propose the convention of a default baseline in  
>>> every  configuration. This is particularly useful from a  
>>> development point of  view. We use this in all Moose projects with  
>>> success.
>>> The scenario is like this:
>>> - default is a baseline (i.e., without explicit versions)
>>> - it represents the current development configuration
>>> - that means that we only work on the default
>>> - every time we want to create an explicit version, we copy default  
>>> to  a corresponding baseline and we create the version
>>> The benefit of this convention is that it provides a simple way to  
>>> depend on a configuration for development without needing to  
>>> update  for every new version.
>>> For example, now we have ConfigurationOfGlamourSeaside and we want  
>>> to  depend on ConfigurationOfSeaside. In the current form, we can  
>>> only  depend on version "3.0.0-alpha5.15". However, for development  
>>> purposes  we would need access to the latest fixes which are not  
>>> yet in a  version. If there would be a default, we could just have  
>>> our default  depend on that one.
>>> What do you think?
>>> Cheers,
>>> Doru
>>> --
>>> www.tudorgirba.com
>>> "No matter how many recipes we know, we still value a chef."
>
> --
> www.tudorgirba.com
>
> "Live like you mean it."
>
Reply | Threaded
Open this post in threaded view
|

Re: default convention

Tudor Girba
Hi,

> Now I'm sorry that I lost the thread, too...
>
> Let me think on your suggestion a bit ... I agree that my suggestion  
> doesn't solve your problem and I like the idea of an explicit pragma  
> better than naming ... I think ...
>
> just a thought ... would #current as a blessing: fill the bill?

I think a blessing does not solve the problem. The same blessing can  
appear in many versions. I want to easily be able to refer to a unique  
baseline.

Btw, the other benefit of a "current" baseline is that I do not have  
to think what to modify. I always modify the current one, instead of  
needing to go in the list to pick the latest one. This simplifies the  
workflow and makes it easy to communicate to others what they should  
do (just like the ConfigurationOf made it pretty easy for people to  
identify starting points).

Cheers,
Doru


> Dale
>
> Tudor Girba wrote:
>> Hi Dale,
>> Sorry for the late reply. I somehow lost track of this thread :(.
>> The problem is that baseline is still a naming convention. So, for  
>> example, if I have #default as a baseline, and #aProject-
>> baseline.xxx  as the baselines, #default will always be the  
>> lastBaseline.
>> Perhaps we could introduce an explicit pragma to distinguish  
>> between  versions, baselines and "current"?
>> Cheers,
>> Doru
>> On 9 Aug 2010, at 21:15, Dale Henrichs wrote:
>>> Tudor,
>>>
>>> I've been mulling this one over a bit and I think I'd like to  
>>> suggest an alternate approach that is a little more general and  
>>> can  be applied in a few more use cases....
>>>
>>> We are talking about project references and I've been bothered  
>>> for  awhile about the fact that when specifying a project  
>>> reference, you  have two choices (don't specify a version and  
>>> you'll always get the  #latestVersion) or specify an explicit  
>>> version ... the  #latestVersion is not bad, but it doesn't address  
>>> the fact the  #baselines should be treated differently. The  
>>> explicit version isn't  real useful when you are specifying a  
>>> baseline .... too restrictive.
>>>
>>> Soo, I think that I'd like to extend the way that versions can be  
>>> specified to include a "dynamic version spec".
>>>
>>> The idea is that you can specify a symbol as a _project_ version  
>>> string:
>>>
>>> - '#latestVersion' is equivalent to the current no specification
>>> - '#lastVersion' allows for pulling in the #lastVersion of a project
>>> - '#lastBaseline' for pulling in the latest #baseline version
>>>
>>> These specifications can be used from within a baseline or a  
>>> version  spec, but only for project specs. Note that you can use a  
>>> Symbol or  a String for the spec (i.e., '#latestVersion' and  
>>> #latestVersion  should work).
>>>
>>> I also propose adding a corresponding #lastBaseline to  
>>> MetacelloProject.
>>>
>>> If I'm not mistaken, this will satisfy your requirement for  
>>> referencing other projects, since I believe that in your case the  
>>> meaning of "current development configuration" is the latest  
>>> version  of everything...
>>>
>>> A convention isn't a bad idea, but we need an answer for  
>>> configurations that don't follow the convention (or whose  
>>> definition  of default is not really what one wants)...
>>>
>>> I can imagine a situation where I would use #latestBaseline and  
>>> #latestVersion for project specs in the latest baseline and  
>>> latest  version of a configuration, but when I find it necessary  
>>> to create a  new baseline or version, I would be inclined to  
>>> replace the  #latestBaseline and #latestVersion specs with the  
>>> actual baseline  and version, so that the spec would be locked  
>>> down from that point  forward ...
>>>
>>> Dale
>>>
>>> Tudor Girba wrote:
>>>> Hi,
>>>> I would like to propose the convention of a default baseline in  
>>>> every  configuration. This is particularly useful from a  
>>>> development point of  view. We use this in all Moose projects  
>>>> with  success.
>>>> The scenario is like this:
>>>> - default is a baseline (i.e., without explicit versions)
>>>> - it represents the current development configuration
>>>> - that means that we only work on the default
>>>> - every time we want to create an explicit version, we copy  
>>>> default  to  a corresponding baseline and we create the version
>>>> The benefit of this convention is that it provides a simple way  
>>>> to   depend on a configuration for development without needing  
>>>> to  update  for every new version.
>>>> For example, now we have ConfigurationOfGlamourSeaside and we  
>>>> want  to  depend on ConfigurationOfSeaside. In the current form,  
>>>> we can  only  depend on version "3.0.0-alpha5.15". However, for  
>>>> development  purposes  we would need access to the latest fixes  
>>>> which are not  yet in a  version. If there would be a default, we  
>>>> could just have  our default  depend on that one.
>>>> What do you think?
>>>> Cheers,
>>>> Doru
>>>> --
>>>> www.tudorgirba.com
>>>> "No matter how many recipes we know, we still value a chef."
>> --
>> www.tudorgirba.com
>> "Live like you mean it."

--
www.tudorgirba.com

"There are no old things, there are only old ways of looking at them."



Reply | Threaded
Open this post in threaded view
|

Re: default convention

Dale Henrichs
In reply to this post by Tudor Girba
Doru,

I was wondering if you have been following the symbolic version discussion?

In my mind I have imagined that the symbolic versions will address your
desire to have a convention for what has come to be known as the
#bleedingEdgeVersion.

Earlier today, Mariano made a good argument against having a default
behavior for #stableVersion, but I think that there is a case for having
  default behaviors defined for #developmentVersin and #bleedingEdge, so
that we would move from a convention into being able to depend upon
there being a definition for #bleedingEdge...

If we do have a default behavior for #bleedingEdge, it should be
implemented as a standard method in the config which is consistent with
the lookup/message send pattern I am proposing ...

Regardless, I am interested to hear your thoughts on the directions we
are going with symbolic versions as it relates to your desire for a
'default convention'.

Dale

Tudor Girba wrote:

> Hi,
>
> I would like to propose the convention of a default baseline in every  
> configuration. This is particularly useful from a development point of  
> view. We use this in all Moose projects with success.
>
> The scenario is like this:
> - default is a baseline (i.e., without explicit versions)
> - it represents the current development configuration
> - that means that we only work on the default
> - every time we want to create an explicit version, we copy default to  
> a corresponding baseline and we create the version
>
> The benefit of this convention is that it provides a simple way to  
> depend on a configuration for development without needing to update  
> for every new version.
>
> For example, now we have ConfigurationOfGlamourSeaside and we want to  
> depend on ConfigurationOfSeaside. In the current form, we can only  
> depend on version "3.0.0-alpha5.15". However, for development purposes  
> we would need access to the latest fixes which are not yet in a  
> version. If there would be a default, we could just have our default  
> depend on that one.
>
> What do you think?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "No matter how many recipes we know, we still value a chef."
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: default convention

Mariano Martinez Peck


On Wed, Sep 29, 2010 at 7:31 PM, Dale Henrichs <[hidden email]> wrote:
Doru,

I was wondering if you have been following the symbolic version discussion?

In my mind I have imagined that the symbolic versions will address your desire to have a convention for what has come to be known as the #bleedingEdgeVersion.

Earlier today, Mariano made a good argument against having a default behavior for #stableVersion, but I think that there is a case for having  default behaviors defined for #developmentVersin and #bleedingEdge, so that we would move from a convention into being able to depend upon there being a definition for #bleedingEdge...


:)   My ideal would be: no default in Metacello, but Metacello be flexible enough so that a Configuration can define a default if wanted :)   like Moose here
This is why maybe having the methods is worth it since they can be overridden.
 
If we do have a default behavior for #bleedingEdge, it should be implemented as a standard method in the config which is consistent with the lookup/message send pattern I am proposing ...

Regardless, I am interested to hear your thoughts on the directions we are going with symbolic versions as it relates to your desire for a 'default convention'.

Dale


Tudor Girba wrote:
Hi,

I would like to propose the convention of a default baseline in every  configuration. This is particularly useful from a development point of  view. We use this in all Moose projects with success.

The scenario is like this:
- default is a baseline (i.e., without explicit versions)
- it represents the current development configuration
- that means that we only work on the default
- every time we want to create an explicit version, we copy default to  a corresponding baseline and we create the version

The benefit of this convention is that it provides a simple way to  depend on a configuration for development without needing to update  for every new version.

For example, now we have ConfigurationOfGlamourSeaside and we want to  depend on ConfigurationOfSeaside. In the current form, we can only  depend on version "3.0.0-alpha5.15". However, for development purposes  we would need access to the latest fixes which are not yet in a  version. If there would be a default, we could just have our default  depend on that one.

What do you think?

Cheers,
Doru

--
www.tudorgirba.com

"No matter how many recipes we know, we still value a chef."








Reply | Threaded
Open this post in threaded view
|

Re: default convention

stephane ducasse-2
mariano the problem with methods and behavior overwritting is that you will not be able to build analysis.
This the difference between a declarative model and an imperative executable one.

Stef

On Sep 29, 2010, at 7:34 PM, Mariano Martinez Peck wrote:

>
>
> On Wed, Sep 29, 2010 at 7:31 PM, Dale Henrichs <[hidden email]> wrote:
> Doru,
>
> I was wondering if you have been following the symbolic version discussion?
>
> In my mind I have imagined that the symbolic versions will address your desire to have a convention for what has come to be known as the #bleedingEdgeVersion.
>
> Earlier today, Mariano made a good argument against having a default behavior for #stableVersion, but I think that there is a case for having  default behaviors defined for #developmentVersin and #bleedingEdge, so that we would move from a convention into being able to depend upon there being a definition for #bleedingEdge...
>
>
> :)   My ideal would be: no default in Metacello, but Metacello be flexible enough so that a Configuration can define a default if wanted :)   like Moose here
> This is why maybe having the methods is worth it since they can be overridden.
>  
> If we do have a default behavior for #bleedingEdge, it should be implemented as a standard method in the config which is consistent with the lookup/message send pattern I am proposing ...
>
> Regardless, I am interested to hear your thoughts on the directions we are going with symbolic versions as it relates to your desire for a 'default convention'.
>
> Dale
>
>
> Tudor Girba wrote:
> Hi,
>
> I would like to propose the convention of a default baseline in every  configuration. This is particularly useful from a development point of  view. We use this in all Moose projects with success.
>
> The scenario is like this:
> - default is a baseline (i.e., without explicit versions)
> - it represents the current development configuration
> - that means that we only work on the default
> - every time we want to create an explicit version, we copy default to  a corresponding baseline and we create the version
>
> The benefit of this convention is that it provides a simple way to  depend on a configuration for development without needing to update  for every new version.
>
> For example, now we have ConfigurationOfGlamourSeaside and we want to  depend on ConfigurationOfSeaside. In the current form, we can only  depend on version "3.0.0-alpha5.15". However, for development purposes  we would need access to the latest fixes which are not yet in a  version. If there would be a default, we could just have our default  depend on that one.
>
> What do you think?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "No matter how many recipes we know, we still value a chef."
>
>
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: default convention

Dale Henrichs
In reply to this post by Mariano Martinez Peck
Mariano Martinez Peck wrote:

>
>
> On Wed, Sep 29, 2010 at 7:31 PM, Dale Henrichs <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Doru,
>
>     I was wondering if you have been following the symbolic version
>     discussion?
>
>     In my mind I have imagined that the symbolic versions will address
>     your desire to have a convention for what has come to be known as
>     the #bleedingEdgeVersion.
>
>     Earlier today, Mariano made a good argument against having a default
>     behavior for #stableVersion, but I think that there is a case for
>     having  default behaviors defined for #developmentVersin and
>     #bleedingEdge, so that we would move from a convention into being
>     able to depend upon there being a definition for #bleedingEdge...
>
>
> :)   My ideal would be: no default in Metacello, but Metacello be
> flexible enough so that a Configuration can define a default if wanted
> :)   like Moose here
> This is why maybe having the methods is worth it since they can be
> overridden.

I understand, but I think that #bleedingEdge is a special case...The
reason that Doru requested this in the first place is that it is
difficult for a user of a project to use the #bleedingEdge for _other_
projects.

The "causing confusion" argument doesn't hold for #bleedingEdge ... the
whole intent of bleedingEdge is to load the absolute latest version of
every package in every project so unexpected behavior is the rule rather
than the exception. Having a default bleedingEdge would mean that a
project maintainer doesn't have to think about what the bleedingEdge
would be, since the default for bleedingEdge is adequate 90% of the time.

Finally, I would implement the default behavior by including a
#bleedingEdge method in the standard template making it a defacto
default and users who don't want to support bleedingEdge behaviour can
remove the #bleedingEdge method from their configuration.

So I think we just might be in agreement here:)

Dale
Reply | Threaded
Open this post in threaded view
|

Re: default convention

Dale Henrichs
In reply to this post by stephane ducasse-2
stephane ducasse wrote:
> mariano the problem with methods and behavior overwritting is that you will not be able to build analysis.
> This the difference between a declarative model and an imperative executable one.
>
> Stef

Stef,

We _are_ walking a fine line in using methods as a backup to doing a
direct lookup, however, the message could be sent during spec
construction (unlike the doit methods which are evaluated at load time).

The project spec that is produced would be declarative, because all of
the symbolic versions (whether or not explicitly declared in the config
or defined via message send) would be resolved to a specific version ...

Can we have our cake and eat it too?

Dale
Reply | Threaded
Open this post in threaded view
|

Re: default convention

stephane ducasse-2

On Sep 29, 2010, at 8:43 PM, Dale Henrichs wrote:

> stephane ducasse wrote:
>> mariano the problem with methods and behavior overwritting is that you will not be able to build analysis.
>> This the difference between a declarative model and an imperative executable one. Stef
>
> Stef,
>
> We _are_ walking a fine line in using methods as a backup to doing a direct lookup, however, the message could be sent during spec construction (unlike the doit methods which are evaluated at load time).
>
> The project spec that is produced would be declarative, because all of the symbolic versions (whether or not explicitly declared in the config or defined via message send) would be resolved to a specific version ...
>
> Can we have our cake and eat it too?

that I'm not sure or it means that the specification of the hooks is clear enough so that overriding returns elements that are conceptually the
same as the default ones. In such a case we can build tools that do not care how the results are computed but just need the results.
In such a case it can work else we will have black all inside a declarative model. Like the postscript in packages. there is no way to build a real
package merging tools or we get do post1 and post2 not knowing what there are doing.
So we are in sync

>
> Dale

Reply | Threaded
Open this post in threaded view
|

Re: default convention

Mariano Martinez Peck
In reply to this post by Dale Henrichs


On Wed, Sep 29, 2010 at 8:24 PM, Dale Henrichs <[hidden email]> wrote:
Mariano Martinez Peck wrote:



On Wed, Sep 29, 2010 at 7:31 PM, Dale Henrichs <[hidden email] <mailto:[hidden email]>> wrote:

   Doru,

   I was wondering if you have been following the symbolic version
   discussion?

   In my mind I have imagined that the symbolic versions will address
   your desire to have a convention for what has come to be known as
   the #bleedingEdgeVersion.

   Earlier today, Mariano made a good argument against having a default
   behavior for #stableVersion, but I think that there is a case for
   having  default behaviors defined for #developmentVersin and
   #bleedingEdge, so that we would move from a convention into being
   able to depend upon there being a definition for #bleedingEdge...


:)   My ideal would be: no default in Metacello, but Metacello be flexible enough so that a Configuration can define a default if wanted :)   like Moose here
This is why maybe having the methods is worth it since they can be overridden.

I understand, but I think that #bleedingEdge is a special case...The reason that Doru requested this in the first place is that it is difficult for a user of a project to use the #bleedingEdge for _other_ projects.

The "causing confusion" argument doesn't hold for #bleedingEdge ... the whole intent of bleedingEdge is to load the absolute latest version of every package in every project so unexpected behavior is the rule rather than the exception. Having a default bleedingEdge would mean that a project maintainer doesn't have to think about what the bleedingEdge would be, since the default for bleedingEdge is adequate 90% of the time.

Finally, I would implement the default behavior by including a #bleedingEdge method in the standard template making it a defacto default and users who don't want to support bleedingEdge behaviour can remove the #bleedingEdge method from their configuration.

So I think we just might be in agreement here:)


Excellent. I agree.
 
Dale

Reply | Threaded
Open this post in threaded view
|

Re: default convention

Mariano Martinez Peck
In reply to this post by stephane ducasse-2


On Wed, Sep 29, 2010 at 8:24 PM, stephane ducasse <[hidden email]> wrote:
mariano the problem with methods and behavior overwritting is that you will not be able to build analysis.
This the difference between a declarative model and an imperative executable one.

I didn't understand. Don't worry, on Friday you can explain me :)
 

Stef

On Sep 29, 2010, at 7:34 PM, Mariano Martinez Peck wrote:

>
>
> On Wed, Sep 29, 2010 at 7:31 PM, Dale Henrichs <[hidden email]> wrote:
> Doru,
>
> I was wondering if you have been following the symbolic version discussion?
>
> In my mind I have imagined that the symbolic versions will address your desire to have a convention for what has come to be known as the #bleedingEdgeVersion.
>
> Earlier today, Mariano made a good argument against having a default behavior for #stableVersion, but I think that there is a case for having  default behaviors defined for #developmentVersin and #bleedingEdge, so that we would move from a convention into being able to depend upon there being a definition for #bleedingEdge...
>
>
> :)   My ideal would be: no default in Metacello, but Metacello be flexible enough so that a Configuration can define a default if wanted :)   like Moose here
> This is why maybe having the methods is worth it since they can be overridden.
>
> If we do have a default behavior for #bleedingEdge, it should be implemented as a standard method in the config which is consistent with the lookup/message send pattern I am proposing ...
>
> Regardless, I am interested to hear your thoughts on the directions we are going with symbolic versions as it relates to your desire for a 'default convention'.
>
> Dale
>
>
> Tudor Girba wrote:
> Hi,
>
> I would like to propose the convention of a default baseline in every  configuration. This is particularly useful from a development point of  view. We use this in all Moose projects with success.
>
> The scenario is like this:
> - default is a baseline (i.e., without explicit versions)
> - it represents the current development configuration
> - that means that we only work on the default
> - every time we want to create an explicit version, we copy default to  a corresponding baseline and we create the version
>
> The benefit of this convention is that it provides a simple way to  depend on a configuration for development without needing to update  for every new version.
>
> For example, now we have ConfigurationOfGlamourSeaside and we want to  depend on ConfigurationOfSeaside. In the current form, we can only  depend on version "3.0.0-alpha5.15". However, for development purposes  we would need access to the latest fixes which are not yet in a  version. If there would be a default, we could just have our default  depend on that one.
>
> What do you think?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "No matter how many recipes we know, we still value a chef."
>
>
>
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: default convention

Alexandre Bergel-5
In reply to this post by stephane ducasse-2
> mariano the problem with methods and behavior overwritting is that you will not be able to build analysis.
> This the difference between a declarative model and an imperative executable one.

+1

Alexandre

>
> On Sep 29, 2010, at 7:34 PM, Mariano Martinez Peck wrote:
>
>>
>>
>> On Wed, Sep 29, 2010 at 7:31 PM, Dale Henrichs <[hidden email]> wrote:
>> Doru,
>>
>> I was wondering if you have been following the symbolic version discussion?
>>
>> In my mind I have imagined that the symbolic versions will address your desire to have a convention for what has come to be known as the #bleedingEdgeVersion.
>>
>> Earlier today, Mariano made a good argument against having a default behavior for #stableVersion, but I think that there is a case for having  default behaviors defined for #developmentVersin and #bleedingEdge, so that we would move from a convention into being able to depend upon there being a definition for #bleedingEdge...
>>
>>
>> :)   My ideal would be: no default in Metacello, but Metacello be flexible enough so that a Configuration can define a default if wanted :)   like Moose here
>> This is why maybe having the methods is worth it since they can be overridden.
>>
>> If we do have a default behavior for #bleedingEdge, it should be implemented as a standard method in the config which is consistent with the lookup/message send pattern I am proposing ...
>>
>> Regardless, I am interested to hear your thoughts on the directions we are going with symbolic versions as it relates to your desire for a 'default convention'.
>>
>> Dale
>>
>>
>> Tudor Girba wrote:
>> Hi,
>>
>> I would like to propose the convention of a default baseline in every  configuration. This is particularly useful from a development point of  view. We use this in all Moose projects with success.
>>
>> The scenario is like this:
>> - default is a baseline (i.e., without explicit versions)
>> - it represents the current development configuration
>> - that means that we only work on the default
>> - every time we want to create an explicit version, we copy default to  a corresponding baseline and we create the version
>>
>> The benefit of this convention is that it provides a simple way to  depend on a configuration for development without needing to update  for every new version.
>>
>> For example, now we have ConfigurationOfGlamourSeaside and we want to  depend on ConfigurationOfSeaside. In the current form, we can only  depend on version "3.0.0-alpha5.15". However, for development purposes  we would need access to the latest fixes which are not yet in a  version. If there would be a default, we could just have our default  depend on that one.
>>
>> What do you think?
>>
>> Cheers,
>> Doru
>>
>> --
>> www.tudorgirba.com
>>
>> "No matter how many recipes we know, we still value a chef."
>>
>>
>>
>>
>>
>>
>>
>>

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





Reply | Threaded
Open this post in threaded view
|

Re: default convention

Mariano Martinez Peck


On Thu, Sep 30, 2010 at 4:19 PM, Alexandre Bergel <[hidden email]> wrote:
> mariano the problem with methods and behavior overwritting is that you will not be able to build analysis.
> This the difference between a declarative model and an imperative executable one.


I still don't understand. Can someone explain me?
thanks

mariano
 
+1

Alexandre

>
> On Sep 29, 2010, at 7:34 PM, Mariano Martinez Peck wrote:
>
>>
>>
>> On Wed, Sep 29, 2010 at 7:31 PM, Dale Henrichs <[hidden email]> wrote:
>> Doru,
>>
>> I was wondering if you have been following the symbolic version discussion?
>>
>> In my mind I have imagined that the symbolic versions will address your desire to have a convention for what has come to be known as the #bleedingEdgeVersion.
>>
>> Earlier today, Mariano made a good argument against having a default behavior for #stableVersion, but I think that there is a case for having  default behaviors defined for #developmentVersin and #bleedingEdge, so that we would move from a convention into being able to depend upon there being a definition for #bleedingEdge...
>>
>>
>> :)   My ideal would be: no default in Metacello, but Metacello be flexible enough so that a Configuration can define a default if wanted :)   like Moose here
>> This is why maybe having the methods is worth it since they can be overridden.
>>
>> If we do have a default behavior for #bleedingEdge, it should be implemented as a standard method in the config which is consistent with the lookup/message send pattern I am proposing ...
>>
>> Regardless, I am interested to hear your thoughts on the directions we are going with symbolic versions as it relates to your desire for a 'default convention'.
>>
>> Dale
>>
>>
>> Tudor Girba wrote:
>> Hi,
>>
>> I would like to propose the convention of a default baseline in every  configuration. This is particularly useful from a development point of  view. We use this in all Moose projects with success.
>>
>> The scenario is like this:
>> - default is a baseline (i.e., without explicit versions)
>> - it represents the current development configuration
>> - that means that we only work on the default
>> - every time we want to create an explicit version, we copy default to  a corresponding baseline and we create the version
>>
>> The benefit of this convention is that it provides a simple way to  depend on a configuration for development without needing to update  for every new version.
>>
>> For example, now we have ConfigurationOfGlamourSeaside and we want to  depend on ConfigurationOfSeaside. In the current form, we can only  depend on version "3.0.0-alpha5.15". However, for development purposes  we would need access to the latest fixes which are not yet in a  version. If there would be a default, we could just have our default  depend on that one.
>>
>> What do you think?
>>
>> Cheers,
>> Doru
>>
>> --
>> www.tudorgirba.com
>>
>> "No matter how many recipes we know, we still value a chef."
>>
>>
>>
>>
>>
>>
>>
>>

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






12