17 Feb
2011
17 Feb
'11
3:47 p.m.
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
17 Feb
17 Feb
4:24 p.m.
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
4:54 p.m.
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:
--
www.tudorgirba.com
"One cannot do more than one can do."
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:09 p.m.
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:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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:
--
www.tudorgirba.com
"One cannot do more than one can do."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
18 Feb
18 Feb
8:17 p.m.
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.
:)
I remember saying that a lot :)
and I was sad that we could not use moose evolution.
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:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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:
--
www.tudorgirba.com
"One cannot do more than one can do."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
19 Feb
19 Feb
9:54 a.m.
On 18 Feb 2011, at 20:17, Stéphane Ducasse wrote:
--
www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot be done."
On Feb 17, 2011, at 5:09 PM, Alexandre Bergel wrote:
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
> 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.
:)
I remember saying that a lot :)
and I was sad that we could not use moose evolution.
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 17 Feb 2011, at 16:24, Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"One cannot do more than one can do."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
21 Feb
21 Feb
10:17 a.m.
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.
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
--
www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot be
done."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> 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.
:)
I remember saying that a lot :)
and I was sad that we could not use moose evolution.
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"One cannot do more than one can do."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
22 Feb
22 Feb
3:30 p.m.
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.
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
--
www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot be
done."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 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
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "One cannot do more than one can do."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4813
days inactive
4818
days old
7 comments
4 participants
participants (4)
-
Alexandre Bergel -
Alexandre Bergel -
Stéphane Ducasse -
Tudor Girba