Version number for Moose

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

Version number for Moose

Alexandre Bergel
Hi!

I am working on using MetacelloBrowser for Moose. The goal is to make explicit all the versions of Moose and keep a record of them. Each new commit of one of the Moose package or each new version of a dependent library should produce a new version of Moose. I guess we all want that. I use this for Mondrian and I am quite happy.

I propose to use a simple version numbering. Something like 4.3.X where X will increment at each new commit made in one of the packages of Moose.

I have produced version 4.3.1. It loads in the latest Pharo 1.2. However, it contains a bit of hack. I believe that a Configuration version should not depend on the default baseline.
It still contains:
                spec
                        project: 'MooseAlgos for Moose' with: '2.2';
                        project: 'PetitParser for Moose' with: 'default';
                        project: 'DSM for Moose' with: 'default';
                        project: 'Glamour for Moose' with: '2.1';
                        project: 'Mondrian for Moose' with: 'default';
                        project: 'SmallDude for Moose' with: 'default';
                        project: 'Merlin' with: '1.0';
                        project: 'RPackage' with: 'default'.

If you agree with this, I can produce a fix version for each of these package. Does it goes in the right direction? I already produce Version 2.1 of Glamour.

Alexandre

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






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version number for Moose

Alexandre Bergel
Another important topic. Now that each version of moose will be made explicit.
How do we integrate them in Hudson?

If there is a guaranty (that we do not have now) that a version recursively depend on fixed version (and not default), then there is no need to build them.

Cheers,
Alexandre


On 17 Feb 2011, at 11:47, Alexandre Bergel wrote:

> Hi!
>
> I am working on using MetacelloBrowser for Moose. The goal is to make explicit all the versions of Moose and keep a record of them. Each new commit of one of the Moose package or each new version of a dependent library should produce a new version of Moose. I guess we all want that. I use this for Mondrian and I am quite happy.
>
> I propose to use a simple version numbering. Something like 4.3.X where X will increment at each new commit made in one of the packages of Moose.
>
> I have produced version 4.3.1. It loads in the latest Pharo 1.2. However, it contains a bit of hack. I believe that a Configuration version should not depend on the default baseline.
> It still contains:
> spec
> project: 'MooseAlgos for Moose' with: '2.2';
> project: 'PetitParser for Moose' with: 'default';
> project: 'DSM for Moose' with: 'default';
> project: 'Glamour for Moose' with: '2.1';
> project: 'Mondrian for Moose' with: 'default';
> project: 'SmallDude for Moose' with: 'default';
> project: 'Merlin' with: '1.0';
> project: 'RPackage' with: 'default'.
>
> If you agree with this, I can produce a fix version for each of these package. Does it goes in the right direction? I already produce Version 2.1 of Glamour.
>
> Alexandre
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version number for Moose

Tudor Girba
Thanks a lot for all this work.

Actual versions should never depend on baselines because we want them to be reloadable in 10 years.

For the versioning, we should be able to start from the default of Moose and from there create actual versions recursively in all contained packages.

Cheers,
Doru


On 17 Feb 2011, at 16:24, Alexandre Bergel wrote:

> Another important topic. Now that each version of moose will be made explicit.
> How do we integrate them in Hudson?
>
> If there is a guaranty (that we do not have now) that a version recursively depend on fixed version (and not default), then there is no need to build them.
>
> Cheers,
> Alexandre
>
>
> On 17 Feb 2011, at 11:47, Alexandre Bergel wrote:
>
>> Hi!
>>
>> I am working on using MetacelloBrowser for Moose. The goal is to make explicit all the versions of Moose and keep a record of them. Each new commit of one of the Moose package or each new version of a dependent library should produce a new version of Moose. I guess we all want that. I use this for Mondrian and I am quite happy.
>>
>> I propose to use a simple version numbering. Something like 4.3.X where X will increment at each new commit made in one of the packages of Moose.
>>
>> I have produced version 4.3.1. It loads in the latest Pharo 1.2. However, it contains a bit of hack. I believe that a Configuration version should not depend on the default baseline.
>> It still contains:
>> spec
>> project: 'MooseAlgos for Moose' with: '2.2';
>> project: 'PetitParser for Moose' with: 'default';
>> project: 'DSM for Moose' with: 'default';
>> project: 'Glamour for Moose' with: '2.1';
>> project: 'Mondrian for Moose' with: 'default';
>> project: 'SmallDude for Moose' with: 'default';
>> project: 'Merlin' with: '1.0';
>> project: 'RPackage' with: 'default'.
>>
>> If you agree with this, I can produce a fix version for each of these package. Does it goes in the right direction? I already produce Version 2.1 of Glamour.
>>
>> Alexandre
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"One cannot do more than one can do."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version number for Moose

Alexandre Bergel
> Actual versions should never depend on baselines because we want them to be reloadable in 10 years.

Ok, we're in sync.

> For the versioning, we should be able to start from the default of Moose and from there create actual versions recursively in all contained packages.

Indeed. But how to achieve this?
Who should have the responsibility of creating a new version of dependent packages? The author of the package I guess. MetacelloBrowser is a better replacement than Monticello.
I will continue to produce versions of each dependent packages in the meantime.

Having a complete trace of each version of several software will open new doors for analysis...

Alexandre

>
>
> On 17 Feb 2011, at 16:24, Alexandre Bergel wrote:
>
>> Another important topic. Now that each version of moose will be made explicit.
>> How do we integrate them in Hudson?
>>
>> If there is a guaranty (that we do not have now) that a version recursively depend on fixed version (and not default), then there is no need to build them.
>>
>> Cheers,
>> Alexandre
>>
>>
>> On 17 Feb 2011, at 11:47, Alexandre Bergel wrote:
>>
>>> Hi!
>>>
>>> I am working on using MetacelloBrowser for Moose. The goal is to make explicit all the versions of Moose and keep a record of them. Each new commit of one of the Moose package or each new version of a dependent library should produce a new version of Moose. I guess we all want that. I use this for Mondrian and I am quite happy.
>>>
>>> I propose to use a simple version numbering. Something like 4.3.X where X will increment at each new commit made in one of the packages of Moose.
>>>
>>> I have produced version 4.3.1. It loads in the latest Pharo 1.2. However, it contains a bit of hack. I believe that a Configuration version should not depend on the default baseline.
>>> It still contains:
>>> spec
>>> project: 'MooseAlgos for Moose' with: '2.2';
>>> project: 'PetitParser for Moose' with: 'default';
>>> project: 'DSM for Moose' with: 'default';
>>> project: 'Glamour for Moose' with: '2.1';
>>> project: 'Mondrian for Moose' with: 'default';
>>> project: 'SmallDude for Moose' with: 'default';
>>> project: 'Merlin' with: '1.0';
>>> project: 'RPackage' with: 'default'.
>>>
>>> If you agree with this, I can produce a fix version for each of these package. Does it goes in the right direction? I already produce Version 2.1 of Glamour.
>>>
>>> Alexandre
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "One cannot do more than one can do."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version number for Moose

Stéphane Ducasse

On Feb 17, 2011, at 5:09 PM, Alexandre Bergel wrote:

>> Actual versions should never depend on baselines because we want them to be reloadable in 10 years.

I did not get what you mean because the versions should import the baseline?

>
> Ok, we're in sync.
>
>> For the versioning, we should be able to start from the default of Moose and from there create actual versions recursively in all contained packages.
>
> Indeed. But how to achieve this?
> Who should have the responsibility of creating a new version of dependent packages? The author of the package I guess. MetacelloBrowser is a better replacement than Monticello.
> I will continue to produce versions of each dependent packages in the meantime.
>
> Having a complete trace of each version of several software will open new doors for analysis...

:)
I remember saying that a lot :)
and I was sad that we could not use moose evolution.

>
> Alexandre
>
>>
>>
>> On 17 Feb 2011, at 16:24, Alexandre Bergel wrote:
>>
>>> Another important topic. Now that each version of moose will be made explicit.
>>> How do we integrate them in Hudson?
>>>
>>> If there is a guaranty (that we do not have now) that a version recursively depend on fixed version (and not default), then there is no need to build them.
>>>
>>> Cheers,
>>> Alexandre
>>>
>>>
>>> On 17 Feb 2011, at 11:47, Alexandre Bergel wrote:
>>>
>>>> Hi!
>>>>
>>>> I am working on using MetacelloBrowser for Moose. The goal is to make explicit all the versions of Moose and keep a record of them. Each new commit of one of the Moose package or each new version of a dependent library should produce a new version of Moose. I guess we all want that. I use this for Mondrian and I am quite happy.
>>>>
>>>> I propose to use a simple version numbering. Something like 4.3.X where X will increment at each new commit made in one of the packages of Moose.
>>>>
>>>> I have produced version 4.3.1. It loads in the latest Pharo 1.2. However, it contains a bit of hack. I believe that a Configuration version should not depend on the default baseline.
>>>> It still contains:
>>>> spec
>>>> project: 'MooseAlgos for Moose' with: '2.2';
>>>> project: 'PetitParser for Moose' with: 'default';
>>>> project: 'DSM for Moose' with: 'default';
>>>> project: 'Glamour for Moose' with: '2.1';
>>>> project: 'Mondrian for Moose' with: 'default';
>>>> project: 'SmallDude for Moose' with: 'default';
>>>> project: 'Merlin' with: '1.0';
>>>> project: 'RPackage' with: 'default'.
>>>>
>>>> If you agree with this, I can produce a fix version for each of these package. Does it goes in the right direction? I already produce Version 2.1 of Glamour.
>>>>
>>>> Alexandre
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "One cannot do more than one can do."
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version number for Moose

Tudor Girba

On 18 Feb 2011, at 20:17, Stéphane Ducasse wrote:

>
> On Feb 17, 2011, at 5:09 PM, Alexandre Bergel wrote:
>
>>> Actual versions should never depend on baselines because we want them to be reloadable in 10 years.
>
> I did not get what you mean because the versions should import the baseline?

A baseline configuration is just a set of packages, without actual versions. I said that we should not depend on a baseline configuration in an actual version because then we depend on the latest version.

Doru



>> Ok, we're in sync.
>>
>>> For the versioning, we should be able to start from the default of Moose and from there create actual versions recursively in all contained packages.
>>
>> Indeed. But how to achieve this?
>> Who should have the responsibility of creating a new version of dependent packages? The author of the package I guess. MetacelloBrowser is a better replacement than Monticello.
>> I will continue to produce versions of each dependent packages in the meantime.
>>
>> Having a complete trace of each version of several software will open new doors for analysis...
>
> :)
> I remember saying that a lot :)
> and I was sad that we could not use moose evolution.
>
>>
>> Alexandre
>>
>>>
>>>
>>> On 17 Feb 2011, at 16:24, Alexandre Bergel wrote:
>>>
>>>> Another important topic. Now that each version of moose will be made explicit.
>>>> How do we integrate them in Hudson?
>>>>
>>>> If there is a guaranty (that we do not have now) that a version recursively depend on fixed version (and not default), then there is no need to build them.
>>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>
>>>> On 17 Feb 2011, at 11:47, Alexandre Bergel wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> I am working on using MetacelloBrowser for Moose. The goal is to make explicit all the versions of Moose and keep a record of them. Each new commit of one of the Moose package or each new version of a dependent library should produce a new version of Moose. I guess we all want that. I use this for Mondrian and I am quite happy.
>>>>>
>>>>> I propose to use a simple version numbering. Something like 4.3.X where X will increment at each new commit made in one of the packages of Moose.
>>>>>
>>>>> I have produced version 4.3.1. It loads in the latest Pharo 1.2. However, it contains a bit of hack. I believe that a Configuration version should not depend on the default baseline.
>>>>> It still contains:
>>>>> spec
>>>>> project: 'MooseAlgos for Moose' with: '2.2';
>>>>> project: 'PetitParser for Moose' with: 'default';
>>>>> project: 'DSM for Moose' with: 'default';
>>>>> project: 'Glamour for Moose' with: '2.1';
>>>>> project: 'Mondrian for Moose' with: 'default';
>>>>> project: 'SmallDude for Moose' with: 'default';
>>>>> project: 'Merlin' with: '1.0';
>>>>> project: 'RPackage' with: 'default'.
>>>>>
>>>>> If you agree with this, I can produce a fix version for each of these package. Does it goes in the right direction? I already produce Version 2.1 of Glamour.
>>>>>
>>>>> Alexandre
>>>>>
>>>>> --
>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "One cannot do more than one can do."
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Not knowing how to do something is not an argument for how it cannot be done."


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version number for Moose

Stéphane Ducasse
I still do not get it.
For me a baseline is a baseline (set of package name with the required information.
So a version depends on a baseline and specifies specific version information.
So a version depends on baselines. and you just say the inverse so I'm totally confused.

>>>> Actual versions should never depend on baselines because we want them to be reloadable in 10 years.
>>
>> I did not get what you mean because the versions should import the baseline?
>
> A baseline configuration is just a set of packages, without actual versions. I said that we should not depend on a baseline configuration in an actual version because then we depend on the latest version.
>
> Doru
>
>
>
>>> Ok, we're in sync.
>>>
>>>> For the versioning, we should be able to start from the default of Moose and from there create actual versions recursively in all contained packages.
>>>
>>> Indeed. But how to achieve this?
>>> Who should have the responsibility of creating a new version of dependent packages? The author of the package I guess. MetacelloBrowser is a better replacement than Monticello.
>>> I will continue to produce versions of each dependent packages in the meantime.
>>>
>>> Having a complete trace of each version of several software will open new doors for analysis...
>>
>> :)
>> I remember saying that a lot :)
>> and I was sad that we could not use moose evolution.
>>
>>>
>>> Alexandre
>>>
>>>>
>>>>
>>>> On 17 Feb 2011, at 16:24, Alexandre Bergel wrote:
>>>>
>>>>> Another important topic. Now that each version of moose will be made explicit.
>>>>> How do we integrate them in Hudson?
>>>>>
>>>>> If there is a guaranty (that we do not have now) that a version recursively depend on fixed version (and not default), then there is no need to build them.
>>>>>
>>>>> Cheers,
>>>>> Alexandre
>>>>>
>>>>>
>>>>> On 17 Feb 2011, at 11:47, Alexandre Bergel wrote:
>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> I am working on using MetacelloBrowser for Moose. The goal is to make explicit all the versions of Moose and keep a record of them. Each new commit of one of the Moose package or each new version of a dependent library should produce a new version of Moose. I guess we all want that. I use this for Mondrian and I am quite happy.
>>>>>>
>>>>>> I propose to use a simple version numbering. Something like 4.3.X where X will increment at each new commit made in one of the packages of Moose.
>>>>>>
>>>>>> I have produced version 4.3.1. It loads in the latest Pharo 1.2. However, it contains a bit of hack. I believe that a Configuration version should not depend on the default baseline.
>>>>>> It still contains:
>>>>>> spec
>>>>>> project: 'MooseAlgos for Moose' with: '2.2';
>>>>>> project: 'PetitParser for Moose' with: 'default';
>>>>>> project: 'DSM for Moose' with: 'default';
>>>>>> project: 'Glamour for Moose' with: '2.1';
>>>>>> project: 'Mondrian for Moose' with: 'default';
>>>>>> project: 'SmallDude for Moose' with: 'default';
>>>>>> project: 'Merlin' with: '1.0';
>>>>>> project: 'RPackage' with: 'default'.
>>>>>>
>>>>>> If you agree with this, I can produce a fix version for each of these package. Does it goes in the right direction? I already produce Version 2.1 of Glamour.
>>>>>>
>>>>>> Alexandre
>>>>>>
>>>>>> --
>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "One cannot do more than one can do."
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Not knowing how to do something is not an argument for how it cannot be done."
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version number for Moose

abergel
Hi Stef,

You got it right. When I said import, I was referring to the metacello terminology: a version imports a baseline. This is the same concept than your "depends on" in your "So a version depends on a baseline".

E.g.,
ConfigurationOfDSM>>version20beta4: spec
        <version: '2.0-beta.4' imports: #('2.0-beta.2-baseline')>
        ...

Alexandre


On 21 Feb 2011, at 06:17, Stéphane Ducasse wrote:

> I still do not get it.
> For me a baseline is a baseline (set of package name with the required information.
> So a version depends on a baseline and specifies specific version information.
> So a version depends on baselines. and you just say the inverse so I'm totally confused.
>
>>>>> Actual versions should never depend on baselines because we want them to be reloadable in 10 years.
>>>
>>> I did not get what you mean because the versions should import the baseline?
>>
>> A baseline configuration is just a set of packages, without actual versions. I said that we should not depend on a baseline configuration in an actual version because then we depend on the latest version.
>>
>> Doru
>>
>>
>>
>>>> Ok, we're in sync.
>>>>
>>>>> For the versioning, we should be able to start from the default of Moose and from there create actual versions recursively in all contained packages.
>>>>
>>>> Indeed. But how to achieve this?
>>>> Who should have the responsibility of creating a new version of dependent packages? The author of the package I guess. MetacelloBrowser is a better replacement than Monticello.
>>>> I will continue to produce versions of each dependent packages in the meantime.
>>>>
>>>> Having a complete trace of each version of several software will open new doors for analysis...
>>>
>>> :)
>>> I remember saying that a lot :)
>>> and I was sad that we could not use moose evolution.
>>>
>>>>
>>>> Alexandre
>>>>
>>>>>
>>>>>
>>>>> On 17 Feb 2011, at 16:24, Alexandre Bergel wrote:
>>>>>
>>>>>> Another important topic. Now that each version of moose will be made explicit.
>>>>>> How do we integrate them in Hudson?
>>>>>>
>>>>>> If there is a guaranty (that we do not have now) that a version recursively depend on fixed version (and not default), then there is no need to build them.
>>>>>>
>>>>>> Cheers,
>>>>>> Alexandre
>>>>>>
>>>>>>
>>>>>> On 17 Feb 2011, at 11:47, Alexandre Bergel wrote:
>>>>>>
>>>>>>> Hi!
>>>>>>>
>>>>>>> I am working on using MetacelloBrowser for Moose. The goal is to make explicit all the versions of Moose and keep a record of them. Each new commit of one of the Moose package or each new version of a dependent library should produce a new version of Moose. I guess we all want that. I use this for Mondrian and I am quite happy.
>>>>>>>
>>>>>>> I propose to use a simple version numbering. Something like 4.3.X where X will increment at each new commit made in one of the packages of Moose.
>>>>>>>
>>>>>>> I have produced version 4.3.1. It loads in the latest Pharo 1.2. However, it contains a bit of hack. I believe that a Configuration version should not depend on the default baseline.
>>>>>>> It still contains:
>>>>>>> spec
>>>>>>> project: 'MooseAlgos for Moose' with: '2.2';
>>>>>>> project: 'PetitParser for Moose' with: 'default';
>>>>>>> project: 'DSM for Moose' with: 'default';
>>>>>>> project: 'Glamour for Moose' with: '2.1';
>>>>>>> project: 'Mondrian for Moose' with: 'default';
>>>>>>> project: 'SmallDude for Moose' with: 'default';
>>>>>>> project: 'Merlin' with: '1.0';
>>>>>>> project: 'RPackage' with: 'default'.
>>>>>>>
>>>>>>> If you agree with this, I can produce a fix version for each of these package. Does it goes in the right direction? I already produce Version 2.1 of Glamour.
>>>>>>>
>>>>>>> Alexandre
>>>>>>>
>>>>>>> --
>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>> --
>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "One cannot do more than one can do."
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Not knowing how to do something is not an argument for how it cannot be done."
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev