Hi Stef,
As I mentioned before, default represents the work in progress. It can happen that the work in progress is the same as the previously released version, and that is why you will see duplication.
Another possibility would be to reuse the previous configuration and just mention the delta (of adding new packages), but I am not sure this would scale in the long run.
So, the current process is: - work on default - when we release, we copy the method in a new baselineXXX - we create a hardcoded version in versionXXX
Cheers, Doru
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Yeh,
Now, I understand the process... (I am slow :) )
But, in this process we must specify versions and maintain it. Is there a solution (in monticello maybe) to say a version of a package is stable. So in this case, we can say "I want last stable version of my package" and we do not need to maintain ConfigurationOf.
Maybe this discussion is more global than moose community, So I copy it in pharo mailing list.
Jannik
On Dec 3, 2009, at 13:15 , Tudor Girba wrote:
Hi Stef,
As I mentioned before, default represents the work in progress. It can happen that the work in progress is the same as the previously released version, and that is why you will see duplication.
Another possibility would be to reuse the previous configuration and just mention the delta (of adding new packages), but I am not sure this would scale in the long run.
So, the current process is:
- work on default
- when we release, we copy the method in a new baselineXXX
- we create a hardcoded version in versionXXX
Cheers, Doru
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Dec 3, 2009, at 1:40 PM, Laval Jannik wrote:
Yeh,
Now, I understand the process... (I am slow :) )
But, in this process we must specify versions and maintain it. Is there a solution (in monticello maybe) to say a version of a package is stable. So in this case, we can say "I want last stable version of my package" and we do not need to maintain ConfigurationOf.
The problem is that it's not one package... your system will be 20 packges. You can say " load the latest of all, that works". But: now I want to load the version that worked so great last month. Which set of packages exactly where that?
Tagging single packages as "release" will not help, as you don't have the info which released package works with which other released package.
Marcus
Hi,
Not every loading strategy have the same goal or the same context.
Sub projects will be developed and published in their own context without taking into account the overall project. However, when maintaining the overall project, I want to be able to say "load latest" so that I can easily load everything and check whether everything still holds together.
For overall release management, I do not want to rely on "load latest". Instead I will release a coherent version when I see that it works. This will be a fixed set of packages with exact versions that will work together.
Cheers, Doru
On 3 Dec 2009, at 14:21, Marcus Denker wrote:
On Dec 3, 2009, at 1:40 PM, Laval Jannik wrote:
Yeh,
Now, I understand the process... (I am slow :) )
But, in this process we must specify versions and maintain it. Is there a solution (in monticello maybe) to say a version of a package is stable. So in this case, we can say "I want last stable version of my package" and we do not need to maintain ConfigurationOf.
The problem is that it's not one package... your system will be 20 packges. You can say " load the latest of all, that works". But: now I want to load the version that worked so great last month. Which set of packages exactly where that?
Tagging single packages as "release" will not help, as you don't have the info which released package works with which other released package.
Marcus _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Obvious things are difficult to teach."
Still still still you can always have a map (a map of all the components you loaded that they work or not). This is orthogonal to a release or just publications. This is a sofware artefact. I know that you know it. The fact to have map is orthogonal of the choice latest or one version. I just write that for others following our discussion....
Stef
On Dec 3, 2009, at 3:59 PM, Tudor Girba wrote:
Hi,
Not every loading strategy have the same goal or the same context.
Sub projects will be developed and published in their own context without taking into account the overall project. However, when maintaining the overall project, I want to be able to say "load latest" so that I can easily load everything and check whether everything still holds together.
For overall release management, I do not want to rely on "load latest". Instead I will release a coherent version when I see that it works. This will be a fixed set of packages with exact versions that will work together.
Cheers, Doru
On 3 Dec 2009, at 14:21, Marcus Denker wrote:
On Dec 3, 2009, at 1:40 PM, Laval Jannik wrote:
Yeh,
Now, I understand the process... (I am slow :) )
But, in this process we must specify versions and maintain it. Is there a solution (in monticello maybe) to say a version of a package is stable. So in this case, we can say "I want last stable version of my package" and we do not need to maintain ConfigurationOf.
The problem is that it's not one package... your system will be 20 packges. You can say " load the latest of all, that works". But: now I want to load the version that worked so great last month. Which set of packages exactly where that?
Tagging single packages as "release" will not help, as you don't have the info which released package works with which other released package.
Marcus _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Obvious things are difficult to teach."
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
In a Metacello context.
The map of packages and their relationships is called a #baseline version. If one loads a #baseline version the latest version of each package is loaded. The "structure" is stable but loading a #baseline version is a risky proposition for everyone except project developers themselves who are prepared to address load-time conflicts/bugs.
A #development version, imports structure from the #baseline, but a specific package version is supplied for each Monticello package or project. When a development version is loaded, the explicit list of package versions are loaded. IN a #development version, the package versions are not finalized and may change over time. When a #development version is saved, there is an presumption that some level of testing has gone on and that the package versions are expected to work together. One can go to a particular version of the package in which the configuration is saved and expect to load the same packages....However, the list of package versions will change over time.
For all other 'released' versions, (beta, release, alpha, stable, etc.) it is expected that the list of package versions will never change - the code base may still be alpha, but it is a stable known point with respect to package versions.
(BTW, I've added the metacello group to this cross-posted message:)
Dale ----- "Stéphane Ducasse" stephane.ducasse@inria.fr wrote:
| Still still still you can always have a map (a map of all the | components you loaded that they work or not). | This is orthogonal to a release or just publications. This is a | sofware artefact. I know that you know it. | The fact to have map is orthogonal of the choice latest or one | version. | I just write that for others following our discussion.... | | Stef | | | | On Dec 3, 2009, at 3:59 PM, Tudor Girba wrote: | | > Hi, | > | > Not every loading strategy have the same goal or the same context. | > | > Sub projects will be developed and published in their own context | > without taking into account the overall project. However, when | > maintaining the overall project, I want to be able to say "load | > latest" so that I can easily load everything and check whether | > everything still holds together. | > | > For overall release management, I do not want to rely on "load | > latest". Instead I will release a coherent version when I see that | it | > works. This will be a fixed set of packages with exact versions that | | > will work together. | > | > Cheers, | > Doru | > | > | > On 3 Dec 2009, at 14:21, Marcus Denker wrote: | > | >> | >> On Dec 3, 2009, at 1:40 PM, Laval Jannik wrote: | >> | >>> Yeh, | >>> | >>> Now, I understand the process... (I am slow :) ) | >>> | >>> But, in this process we must specify versions and maintain it. | >>> Is there a solution (in monticello maybe) to say a version of a | >>> package is stable. | >>> So in this case, we can say "I want last stable version of my | >>> package" and we do not need to maintain ConfigurationOf. | >>> | >> | >> The problem is that it's not one package... your system will be 20 | | >> packges. You can say " load the latest of all, that works". | >> But: now I want to load the version that worked so great last | month. | >> Which set of packages exactly where that? | >> | >> Tagging single packages as "release" will not help, as you don't | >> have the info which released package works with which other | >> released package. | >> | >> | >> Marcus | >> _______________________________________________ | >> Moose-dev mailing list | >> Moose-dev@iam.unibe.ch | >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev | > | > -- | > www.tudorgirba.com | > | > "Obvious things are difficult to teach." | > | > | > | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project@lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
apparently we had a differetn definition of map. my point is that we need map with exact numbers of component to be able to reload and build more. Now I like the baseline idea.
On Dec 3, 2009, at 8:14 PM, Dale Henrichs wrote:
In a Metacello context.
The map of packages and their relationships is called a #baseline version. If one loads a #baseline version the latest version of each package is loaded. The "structure" is stable but loading a #baseline version is a risky proposition for everyone except project developers themselves who are prepared to address load-time conflicts/bugs.
A #development version, imports structure from the #baseline, but a specific package version is supplied for each Monticello package or project. When a development version is loaded, the explicit list of package versions are loaded. IN a #development version, the package versions are not finalized and may change over time. When a #development version is saved, there is an presumption that some level of testing has gone on and that the package versions are expected to work together. One can go to a particular version of the package in which the configuration is saved and expect to load the same packages....However, the list of package versions will change over time.
For all other 'released' versions, (beta, release, alpha, stable, etc.) it is expected that the list of package versions will never change - the code base may still be alpha, but it is a stable known point with respect to package versions.
(BTW, I've added the metacello group to this cross-posted message:)
Dale ----- "Stéphane Ducasse" stephane.ducasse@inria.fr wrote:
| Still still still you can always have a map (a map of all the | components you loaded that they work or not). | This is orthogonal to a release or just publications. This is a | sofware artefact. I know that you know it. | The fact to have map is orthogonal of the choice latest or one | version. | I just write that for others following our discussion.... | | Stef | | | | On Dec 3, 2009, at 3:59 PM, Tudor Girba wrote: | | > Hi, | > | > Not every loading strategy have the same goal or the same context. | > | > Sub projects will be developed and published in their own context | > without taking into account the overall project. However, when | > maintaining the overall project, I want to be able to say "load | > latest" so that I can easily load everything and check whether | > everything still holds together. | > | > For overall release management, I do not want to rely on "load | > latest". Instead I will release a coherent version when I see that | it | > works. This will be a fixed set of packages with exact versions that | | > will work together. | > | > Cheers, | > Doru | > | > | > On 3 Dec 2009, at 14:21, Marcus Denker wrote: | > | >> | >> On Dec 3, 2009, at 1:40 PM, Laval Jannik wrote: | >> | >>> Yeh, | >>> | >>> Now, I understand the process... (I am slow :) ) | >>> | >>> But, in this process we must specify versions and maintain it. | >>> Is there a solution (in monticello maybe) to say a version of a | >>> package is stable. | >>> So in this case, we can say "I want last stable version of my | >>> package" and we do not need to maintain ConfigurationOf. | >>> | >> | >> The problem is that it's not one package... your system will be 20 | | >> packges. You can say " load the latest of all, that works". | >> But: now I want to load the version that worked so great last | month. | >> Which set of packages exactly where that? | >> | >> Tagging single packages as "release" will not help, as you don't | >> have the info which released package works with which other | >> released package. | >> | >> | >> Marcus | >> _______________________________________________ | >> Moose-dev mailing list | >> Moose-dev@iam.unibe.ch | >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev | > | > -- | > www.tudorgirba.com | > | > "Obvious things are difficult to teach." | > | > | > | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project@lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 3 déc. 2009, at 09:40, Laval Jannik wrote:
Yeh,
Now, I understand the process... (I am slow :) )
But, in this process we must specify versions and maintain it. Is there a solution (in monticello maybe) to say a version of a package is stable. So in this case, we can say "I want last stable version of my package" and we do not need to maintain ConfigurationOf.
The way to do it with Metacello: ConfigurationOfXXX project latestVersion load It takes the latest stable version, i.e. one which is not marked as baseline, broken, or development.
Maybe this discussion is more global than moose community, So I copy it in pharo mailing list.
Jannik
On Dec 3, 2009, at 13:15 , Tudor Girba wrote:
Hi Stef,
As I mentioned before, default represents the work in progress. It can happen that the work in progress is the same as the previously released version, and that is why you will see duplication.
Another possibility would be to reuse the previous configuration and just mention the delta (of adding new packages), but I am not sure this would scale in the long run.
So, the current process is:
- work on default
- when we release, we copy the method in a new baselineXXX
- we create a hardcoded version in versionXXX
Cheers, Doru
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
On Dec 3, 2009, at 5:19 PM, Simon Denier wrote:
The way to do it with Metacello: ConfigurationOfXXX project latestVersion load It takes the latest stable version, i.e. one which is not marked as baseline, broken, or development.
Ok apparently I forgot about broken or dev tag. Thanks for the reminder
but
each time we commit we can generate a new version of the method
for me this is important that we can load the latest version but also that we know all the packages and their versions. We do that all the time in pharo.
The problem with your answer is the granularity of the release, if you release daily then this is ok (may be every week would be ok). But why can we release at each modification. We do that for pharo and this helps spotting bug introdcution. There is a no technical challenges and this would lower frsuatration. Then I do not understand why you change the baseline if there is no new packages. FOr me the baseline is the package/repository structure
Stef
On Dec 3, 2009, at 1:15 PM, Tudor Girba wrote:
Hi Stef,
As I mentioned before, default represents the work in progress. It can happen that the work in progress is the same as the previously released version, and that is why you will see duplication.
Another possibility would be to reuse the previous configuration and just mention the delta (of adding new packages), but I am not sure this would scale in the long run.
So, the current process is:
- work on default
- when we release, we copy the method in a new baselineXXX
- we create a hardcoded version in versionXXX
Cheers, Doru
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I copy the baseline from the default to a released version because the default will change in the future, but version 4.0-beta.2 should not be affected by those changes.
Cheers, Doru
On 3 Dec 2009, at 14:55, Stéphane Ducasse wrote:
but
each time we commit we can generate a new version of the method
for me this is important that we can load the latest version but also that we know all the packages and their versions. We do that all the time in pharo.
The problem with your answer is the granularity of the release, if you release daily then this is ok (may be every week would be ok). But why can we release at each modification. We do that for pharo and this helps spotting bug introdcution. There is a no technical challenges and this would lower frsuatration. Then I do not understand why you change the baseline if there is no new packages. FOr me the baseline is the package/repository structure
Stef
On Dec 3, 2009, at 1:15 PM, Tudor Girba wrote:
Hi Stef,
As I mentioned before, default represents the work in progress. It can happen that the work in progress is the same as the previously released version, and that is why you will see duplication.
Another possibility would be to reuse the previous configuration and just mention the delta (of adding new packages), but I am not sure this would scale in the long run.
So, the current process is:
- work on default
- when we release, we copy the method in a new baselineXXX
- we create a hardcoded version in versionXXX
Cheers, Doru
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Obvious things are difficult to teach."
I copy the baseline from the default to a released version because the default will change in the future, but version 4.0-beta.2 should not be affected by those changes.
I see but I thought that baseline should only change when you change package structure.
Cheers, Doru
On 3 Dec 2009, at 14:55, Stéphane Ducasse wrote:
but
each time we commit we can generate a new version of the method
for me this is important that we can load the latest version but also that we know all the packages and their versions. We do that all the time in pharo.
The problem with your answer is the granularity of the release, if you release daily then this is ok (may be every week would be ok). But why can we release at each modification. We do that for pharo and this helps spotting bug introdcution. There is a no technical challenges and this would lower frsuatration. Then I do not understand why you change the baseline if there is no new packages. FOr me the baseline is the package/repository structure
Stef
On Dec 3, 2009, at 1:15 PM, Tudor Girba wrote:
Hi Stef,
As I mentioned before, default represents the work in progress. It can happen that the work in progress is the same as the previously released version, and that is why you will see duplication.
Another possibility would be to reuse the previous configuration and just mention the delta (of adding new packages), but I am not sure this would scale in the long run.
So, the current process is:
- work on default
- when we release, we copy the method in a new baselineXXX
- we create a hardcoded version in versionXXX
Cheers, Doru
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Obvious things are difficult to teach."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
I copy the baseline from the default to a released version because the default will change in the future, but version 4.0-beta.2 should not be affected by those changes.
I see but I thought that baseline should only change when you change package structure.
Well, yes.
That is why if you know that the baselineForVersion2 did not change since baselineForVersion1, you do not need to copy the baseline and you will just import in version2 baselingForVersion1.
Doru
Cheers, Doru
On 3 Dec 2009, at 14:55, Stéphane Ducasse wrote:
but
each time we commit we can generate a new version of the method
for me this is important that we can load the latest version but also that we know all the packages and their versions. We do that all the time in pharo.
The problem with your answer is the granularity of the release, if you release daily then this is ok (may be every week would be ok). But why can we release at each modification. We do that for pharo and this helps spotting bug introdcution. There is a no technical challenges and this would lower frsuatration. Then I do not understand why you change the baseline if there is no new packages. FOr me the baseline is the package/repository structure
Stef
On Dec 3, 2009, at 1:15 PM, Tudor Girba wrote:
Hi Stef,
As I mentioned before, default represents the work in progress. It can happen that the work in progress is the same as the previously released version, and that is why you will see duplication.
Another possibility would be to reuse the previous configuration and just mention the delta (of adding new packages), but I am not sure this would scale in the long run.
So, the current process is:
- work on default
- when we release, we copy the method in a new baselineXXX
- we create a hardcoded version in versionXXX
Cheers, Doru
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Obvious things are difficult to teach."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Ok I prefer :) I thought you did the process systematically
So, the current process is:
- work on default
- when we release, we copy the method in a new baselineXXX
- we create a hardcoded version in versionXXX
Cheers, Doru
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Obvious things are difficult to teach."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Dale Henrichs -
Laval Jannik -
Marcus Denker -
Simon Denier -
stephane ducasse -
Stéphane Ducasse -
Tudor Girba