[Pharo-project] removing versions from configurations
Hi, The Moose build broke because the 'default' version was removed from ConfigurationOfRPackage. I fixed it now by using #stable, but that is not the issue. I understand the need for cleaning, but we should be aware that removing versions from configurations can have far reaching ripple effects. Cheers, Doru -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."
On 04/25/2011 03:51 AM, Tudor Girba wrote:
Hi,
The Moose build broke because the 'default' version was removed from ConfigurationOfRPackage.
I fixed it now by using #stable, but that is not the issue.
I understand the need for cleaning, but we should be aware that removing versions from configurations can have far reaching ripple effects.
+100 Dale
Indeed but loading default could have destroyed your image. So RPackage should not be managed with default. Now for stable I'm not sure that I set it up well so watch out. Stef On Apr 25, 2011, at 12:51 PM, Tudor Girba wrote:
Hi,
The Moose build broke because the 'default' version was removed from ConfigurationOfRPackage.
I fixed it now by using #stable, but that is not the issue.
I understand the need for cleaning, but we should be aware that removing versions from configurations can have far reaching ripple effects.
Cheers, Doru
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
Hi Stef, On 25 Apr 2011, at 18:50, Stéphane Ducasse wrote:
Indeed but loading default could have destroyed your image. So RPackage should not be managed with default.
I do not understand. The continuous integration server is there to check these issues. The correspondent would be to load now the current baseline. If that breaks, it breaks and people look at it. Moose is now developed on multiple fronts and serves multiple interests that are not necessarily synchronized. So, we want to depend on latest things because this ensures communication and puts more pressure on synchronizing issues. This is why we want to play with the latest Pharo (hopefully, we will the development to it next week). Every time we depend on something fixed, we introduce the difficulty of migrating to the next version.
Now for stable I'm not sure that I set it up well so watch out.
The tests say that for the use of Moose, RPackage works Ok. Cheers, Doru
Stef
On Apr 25, 2011, at 12:51 PM, Tudor Girba wrote:
Hi,
The Moose build broke because the 'default' version was removed from ConfigurationOfRPackage.
I fixed it now by using #stable, but that is not the issue.
I understand the need for cleaning, but we should be aware that removing versions from configurations can have far reaching ripple effects.
Cheers, Doru
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
-- www.tudorgirba.com "Don't give to get. Just give."
On Apr 25, 2011, at 7:37 PM, Tudor Girba wrote:
Hi Stef,
On 25 Apr 2011, at 18:50, Stéphane Ducasse wrote:
Indeed but loading default could have destroyed your image. So RPackage should not be managed with default.
I do not understand. The continuous integration server is there to check these issues.
the proof is that it did not work.
The correspondent would be to load now the current baseline. If that breaks, it breaks and people look at it.
Moose is now developed on multiple fronts and serves multiple interests that are not necessarily synchronized. So, we want to depend on latest things because this ensures communication and puts more pressure on synchronizing issues. This is why we want to play with the latest Pharo (hopefully, we will the development to it next week).
Every time we depend on something fixed, we introduce the difficulty of migrating to the next version.
yes but this is the price to pay if you want a really robust package system. I cannot work on a system where I cannot rollback and check a given version and I cannot work with a system where I can lose half of my work.
Now for stable I'm not sure that I set it up well so watch out.
The tests say that for the use of Moose, RPackage works Ok.
The problem is that the scenario of Moose is just to create Moose model and RPackage is much more than that. We found conceptual problem with announcement dependencies with benjamin and fix that. Then for example, Rpackage was not in sync with - the announcement changes because it was violating encapsulation (law of demeter bad practice) In addition there are multiple things that now I have to carefully check. Because MC is not nice and we are replicating this aspects and making rpackage brittle because MC is brittle. So sorry but I need to control the version I work with and there is no way I will work on RPackage with default (and yes this is a pain for me too to have to change all the time the configuration but this is the only way). Stef
Cheers, Doru
Stef
On Apr 25, 2011, at 12:51 PM, Tudor Girba wrote:
Hi,
The Moose build broke because the 'default' version was removed from ConfigurationOfRPackage.
I fixed it now by using #stable, but that is not the issue.
I understand the need for cleaning, but we should be aware that removing versions from configurations can have far reaching ripple effects.
Cheers, Doru
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
-- www.tudorgirba.com
"Don't give to get. Just give."
Hi Stef, On 26 Apr 2011, at 09:42, Stéphane Ducasse wrote:
On Apr 25, 2011, at 7:37 PM, Tudor Girba wrote:
Hi Stef,
On 25 Apr 2011, at 18:50, Stéphane Ducasse wrote:
Indeed but loading default could have destroyed your image. So RPackage should not be managed with default.
I do not understand. The continuous integration server is there to check these issues.
the proof is that it did not work.
The correspondent would be to load now the current baseline. If that breaks, it breaks and people look at it.
Moose is now developed on multiple fronts and serves multiple interests that are not necessarily synchronized. So, we want to depend on latest things because this ensures communication and puts more pressure on synchronizing issues. This is why we want to play with the latest Pharo (hopefully, we will the development to it next week).
Every time we depend on something fixed, we introduce the difficulty of migrating to the next version.
yes but this is the price to pay if you want a really robust package system. I cannot work on a system where I cannot rollback and check a given version and I cannot work with a system where I can lose half of my work.
Sure. Just do not work with the baseline then. Although I am sure that when you are developing RPackage, you do want to load the very latest versions of packages :)
Now for stable I'm not sure that I set it up well so watch out.
The tests say that for the use of Moose, RPackage works Ok.
The problem is that the scenario of Moose is just to create Moose model and RPackage is much more than that. We found conceptual problem with announcement dependencies with benjamin and fix that. Then for example, Rpackage was not in sync with - the announcement changes because it was violating encapsulation (law of demeter bad practice) In addition there are multiple things that now I have to carefully check. Because MC is not nice and we are replicating this aspects and making rpackage brittle because MC is brittle.
I understood that. I was just saying that for Moose it looks like it is working. However, we do not test to see what happens if something is loaded in the image after RPackage was installed, so this is why we are probably missing the issue :(.
So sorry but I need to control the version I work with and there is no way I will work on RPackage with default (and yes this is a pain for me too to have to change all the time the configuration but this is the only way).
I do not understand your line of reasoning. You do not have to work with default to provide a default. If you want to work with a specific version, work with a specific version. Default is nothing but a baseline. You did not remove the other baseline, but you removed default. In any case, my message came from the point of view of someone who integrates and it is not related to default. I understand your needs but I wanted to point out the dangers that come with removing a version. Cheers, Doru
Stef
Cheers, Doru
Stef
On Apr 25, 2011, at 12:51 PM, Tudor Girba wrote:
Hi,
The Moose build broke because the 'default' version was removed from ConfigurationOfRPackage.
I fixed it now by using #stable, but that is not the issue.
I understand the need for cleaning, but we should be aware that removing versions from configurations can have far reaching ripple effects.
Cheers, Doru
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
-- www.tudorgirba.com
"Don't give to get. Just give."
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com "It's not how it is, it is how we see it."
yes but this is the price to pay if you want a really robust package system. I cannot work on a system where I cannot rollback and check a given version and I cannot work with a system where I can lose half of my work.
Sure. Just do not work with the baseline then.
I dnu what you mean.
Although I am sure that when you are developing RPackage, you do want to load the very latest versions of packages :)
So sorry but I need to control the version I work with and there is no way I will work on RPackage with default (and yes this is a pain for me too to have to change all the time the configuration but this is the only way).
I do not understand your line of reasoning. You do not have to work with default to provide a default.
because people load the default and code based on the default and after a certain period of time configurations are not updated and this is the mess. So now for RPackage there is no default so that people changing it are FORCED to produce a new configuration with named file.
If you want to work with a specific version, work with a specific version. Default is nothing but a baseline. Indeed I know that
You did not remove the other baseline, but you removed default.
Yes I know. I did it on purpose. No way to load latest using default.
In any case, my message came from the point of view of someone who integrates and it is not related to default. I understand your needs but I wanted to point out the dangers that come with removing a version.
Yes this was an emergency solution because I succeeded to lose code (which did not happen to me over the last 10 years in smalltalk). Now I'm back to the point where - RPackage tests are better - Clean SystemAnnouncements - Green - I have annotated a lot of issues to fix and verify - So I will be able to make progress, add more tests Looks like I control RPackage now. Stef
Hi Stef, On 26 Apr 2011, at 11:35, Stéphane Ducasse wrote:
yes but this is the price to pay if you want a really robust package system. I cannot work on a system where I cannot rollback and check a given version and I cannot work with a system where I can lose half of my work.
Sure. Just do not work with the baseline then.
I dnu what you mean.
Although I am sure that when you are developing RPackage, you do want to load the very latest versions of packages :)
So sorry but I need to control the version I work with and there is no way I will work on RPackage with default (and yes this is a pain for me too to have to change all the time the configuration but this is the only way).
I do not understand your line of reasoning. You do not have to work with default to provide a default.
because people load the default and code based on the default and after a certain period of time configurations are not updated and this is the mess. So now for RPackage there is no default so that people changing it are FORCED to produce a new configuration with named file.
If you want to work with a specific version, work with a specific version. Default is nothing but a baseline. Indeed I know that
You did not remove the other baseline, but you removed default.
Yes I know. I did it on purpose. No way to load latest using default.
But you did not circumvent anything. All I have to do is load the baseline10: and then I get the latest versions of packages :). Anyway, the discussion was simply about the ripple effects of removing a version from a configuration. This is similar to removing a package version from a Monticello repository.
In any case, my message came from the point of view of someone who integrates and it is not related to default. I understand your needs but I wanted to point out the dangers that come with removing a version.
Yes this was an emergency solution because I succeeded to lose code (which did not happen to me over the last 10 years in smalltalk). Now I'm back to the point where - RPackage tests are better - Clean SystemAnnouncements - Green - I have annotated a lot of issues to fix and verify - So I will be able to make progress, add more tests Looks like I control RPackage now.
I am happy you are in control. Cheers, Doru
Stef
-- www.tudorgirba.com "Don't give to get. Just give."
If you want to work with a specific version, work with a specific version. Default is nothing but a baseline. Indeed I know that
You did not remove the other baseline, but you removed default.
Yes I know. I did it on purpose. No way to load latest using default.
But you did not circumvent anything. All I have to do is load the baseline10: and then I get the latest versions of packages :).
yes but this is a different thing that load or loadDefault. It requires extra energy.
Looks like I control RPackage now.
I am happy you are in control.
Me too. I will work a lot on it from thursday. first address some of the flag: I did second understand what cyrille did for the integration with MC write more tests and see where we get. may be implement what we discussed. Stef
participants (3)
-
Dale Henrichs -
Stéphane Ducasse -
Tudor Girba