[Pharo-project] Allow or disable System Update in PharoDev images ?
It is a simple question. Do we allow that or not. Miguel wrote the pros and cons: Pros - Can fix bugs after release - Can aply improvements to the image after release. Cons - Can mess the image of someone by overwriting some overridden method. - Can accidentally update more than intended in someone's image We have to take a decision. Cheers Mariano
without its own update stream, or section in the update file, I think the effect of allowing the Pharo image to update itself based on the core update file would lead to an undefined result? If that is the case I would disable it. I assume this would be replaced by some Metacello 'update stream' ? cheers, Mike 2010/1/10 Mariano Martinez Peck <marianopeck@gmail.com>:
It is a simple question. Do we allow that or not. Miguel wrote the pros and cons:
Pros - Can fix bugs after release - Can aply improvements to the image after release.
Cons - Can mess the image of someone by overwriting some overridden method. - Can accidentally update more than intended in someone's image
We have to take a decision.
Cheers
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, Jan 10, 2010 at 4:56 PM, Michael Roberts <mike@mjr104.co.uk> wrote:
without its own update stream, or section in the update file, I think the effect of allowing the Pharo image to update itself based on the core update file would lead to an undefined result?
Yes. Mostly due to overrides.
If that is the case I would disable it.
I assume this would be replaced by some Metacello 'update stream' ?
That's a good idea. I am not sure how to implement it, but for sure, it will be in a future ;) Maybe 1.1
cheers, Mike
2010/1/10 Mariano Martinez Peck <marianopeck@gmail.com>:
It is a simple question. Do we allow that or not. Miguel wrote the pros and cons:
Pros - Can fix bugs after release - Can aply improvements to the image after release.
Cons - Can mess the image of someone by overwriting some overridden method. - Can accidentally update more than intended in someone's image
We have to take a decision.
Cheers
Mariano
_______________________________________________ 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
I would also rather disable it. We had numerous reports where this failed. I think "the right way" to do it is to have a build server that creates new Pharo images from the PharoCore version (i.e., "nightly builds"). Until we have this automated, one can always grab an up to date PharoCore and build a Pharo image using the Metacello configuration. Adrian On Jan 10, 2010, at 16:59 , Mariano Martinez Peck wrote:
On Sun, Jan 10, 2010 at 4:56 PM, Michael Roberts <mike@mjr104.co.uk> wrote:
without its own update stream, or section in the update file, I think the effect of allowing the Pharo image to update itself based on the core update file would lead to an undefined result?
Yes. Mostly due to overrides.
If that is the case I would disable it.
I assume this would be replaced by some Metacello 'update stream' ?
That's a good idea. I am not sure how to implement it, but for sure, it will be in a future ;) Maybe 1.1
cheers, Mike
2010/1/10 Mariano Martinez Peck <marianopeck@gmail.com>:
It is a simple question. Do we allow that or not. Miguel wrote the pros and cons:
Pros - Can fix bugs after release - Can aply improvements to the image after release.
Cons - Can mess the image of someone by overwriting some overridden method. - Can accidentally update more than intended in someone's image
We have to take a decision.
Cheers
Mariano
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El dom, 10-01-2010 a las 17:32 +0100, Adrian Lienhard escribió:
I would also rather disable it. We had numerous reports where this failed. I think "the right way" to do it is to have a build server that creates new Pharo images from the PharoCore version (i.e., "nightly builds"). Until we have this automated, one can always grab an up to date PharoCore and build a Pharo image using the Metacello configuration.
But this means that the users that downloaded a prior Pharo will be left on the cold and they will not receive bug fixes, including grave bug fixes. They will be informed that must download a new version and move all their code to a new image. This could generate a lot of irritation on the users because maybe they are changing images just because their current image can't apply a one-line fix that could be distributed by the update stream. Big decision I know, but both options have good arguments. Maybe a BIG warning on pressing the System->Update indicating that the update *could* break something in the image and suggesting to save all their work to a monticello package and know the consecuences and then giving them a button to proceed with the update. So if someone doesn't want to update he/she can cancel. If the haven't saved, they cancel and save their work, then proceed with the update. If they have everything saved, just proceed with the update knowing the consequences. What do you think? Cheers
Adrian
On Jan 10, 2010, at 16:59 , Mariano Martinez Peck wrote:
On Sun, Jan 10, 2010 at 4:56 PM, Michael Roberts <mike@mjr104.co.uk> wrote:
without its own update stream, or section in the update file, I think the effect of allowing the Pharo image to update itself based on the core update file would lead to an undefined result?
Yes. Mostly due to overrides.
If that is the case I would disable it.
I assume this would be replaced by some Metacello 'update stream' ?
That's a good idea. I am not sure how to implement it, but for sure, it will be in a future ;) Maybe 1.1
cheers, Mike
2010/1/10 Mariano Martinez Peck <marianopeck@gmail.com>:
It is a simple question. Do we allow that or not. Miguel wrote the pros and cons:
Pros - Can fix bugs after release - Can aply improvements to the image after release.
Cons - Can mess the image of someone by overwriting some overridden method. - Can accidentally update more than intended in someone's image
We have to take a decision.
Cheers
Mariano
_______________________________________________ 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
_______________________________________________ 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
-- Miguel Cobá http://miguel.leugim.com.mx
I agree, it would be nice to have software update for the Pharo images. But as long as it does not reliably work, I think it harms more than it helps. Adrian BTW, I believe one should regularly start with a fresh image, so starting from a new download should not be a big issue anyway On Jan 10, 2010, at 19:22 , Miguel Enrique Cobá Martinez wrote:
El dom, 10-01-2010 a las 17:32 +0100, Adrian Lienhard escribió:
I would also rather disable it. We had numerous reports where this failed. I think "the right way" to do it is to have a build server that creates new Pharo images from the PharoCore version (i.e., "nightly builds"). Until we have this automated, one can always grab an up to date PharoCore and build a Pharo image using the Metacello configuration.
But this means that the users that downloaded a prior Pharo will be left on the cold and they will not receive bug fixes, including grave bug fixes. They will be informed that must download a new version and move all their code to a new image.
This could generate a lot of irritation on the users because maybe they are changing images just because their current image can't apply a one-line fix that could be distributed by the update stream.
Big decision I know, but both options have good arguments. Maybe a BIG warning on pressing the System->Update indicating that the update *could* break something in the image and suggesting to save all their work to a monticello package and know the consecuences and then giving them a button to proceed with the update. So if someone doesn't want to update he/she can cancel. If the haven't saved, they cancel and save their work, then proceed with the update. If they have everything saved, just proceed with the update knowing the consequences. What do you think?
Cheers
Adrian
On Jan 10, 2010, at 16:59 , Mariano Martinez Peck wrote:
On Sun, Jan 10, 2010 at 4:56 PM, Michael Roberts <mike@mjr104.co.uk> wrote:
without its own update stream, or section in the update file, I think the effect of allowing the Pharo image to update itself based on the core update file would lead to an undefined result?
Yes. Mostly due to overrides.
If that is the case I would disable it.
I assume this would be replaced by some Metacello 'update stream' ?
That's a good idea. I am not sure how to implement it, but for sure, it will be in a future ;) Maybe 1.1
cheers, Mike
2010/1/10 Mariano Martinez Peck <marianopeck@gmail.com>:
It is a simple question. Do we allow that or not. Miguel wrote the pros and cons:
Pros - Can fix bugs after release - Can aply improvements to the image after release.
Cons - Can mess the image of someone by overwriting some overridden method. - Can accidentally update more than intended in someone's image
We have to take a decision.
Cheers
Mariano
_______________________________________________ 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
_______________________________________________ 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
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, Jan 10, 2010 at 10:06 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
I agree, it would be nice to have software update for the Pharo images. But as long as it does not reliably work, I think it harms more than it helps.
+1. But...they main question is, do you know in which cases it breaks stuff? ONLY with overrides ? How many overrides do we have from external packages in Core ?
Adrian
BTW, I believe one should regularly start with a fresh image, so starting from a new download should not be a big issue anyway
It depends. For us it is easy. Buy there are other users, that have data in their image and maybe it is a little more complicated than download a package from squeaksource.
On Jan 10, 2010, at 19:22 , Miguel Enrique Cobá Martinez wrote:
El dom, 10-01-2010 a las 17:32 +0100, Adrian Lienhard escribió:
I would also rather disable it. We had numerous reports where this failed. I think "the right way" to do it is to have a build server that creates new Pharo images from the PharoCore version (i.e., "nightly builds"). Until we have this automated, one can always grab an up to date PharoCore and build a Pharo image using the Metacello configuration.
But this means that the users that downloaded a prior Pharo will be left on the cold and they will not receive bug fixes, including grave bug fixes. They will be informed that must download a new version and move all their code to a new image.
This could generate a lot of irritation on the users because maybe they are changing images just because their current image can't apply a one-line fix that could be distributed by the update stream.
Big decision I know, but both options have good arguments. Maybe a BIG warning on pressing the System->Update indicating that the update *could* break something in the image and suggesting to save all their work to a monticello package and know the consecuences and then giving them a button to proceed with the update. So if someone doesn't want to update he/she can cancel. If the haven't saved, they cancel and save their work, then proceed with the update. If they have everything saved, just proceed with the update knowing the consequences. What do you think?
Cheers
Adrian
On Jan 10, 2010, at 16:59 , Mariano Martinez Peck wrote:
On Sun, Jan 10, 2010 at 4:56 PM, Michael Roberts <mike@mjr104.co.uk> wrote:
without its own update stream, or section in the update file, I think the effect of allowing the Pharo image to update itself based on the core update file would lead to an undefined result?
Yes. Mostly due to overrides.
If that is the case I would disable it.
I assume this would be replaced by some Metacello 'update stream' ?
That's a good idea. I am not sure how to implement it, but for sure, it will be in a future ;) Maybe 1.1
cheers, Mike
2010/1/10 Mariano Martinez Peck <marianopeck@gmail.com>:
It is a simple question. Do we allow that or not. Miguel wrote the pros and cons:
Pros - Can fix bugs after release - Can aply improvements to the image after release.
Cons - Can mess the image of someone by overwriting some overridden method. - Can accidentally update more than intended in someone's image
We have to take a decision.
Cheers
Mariano
_______________________________________________ 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
_______________________________________________ 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
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ 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
2010/1/10 Mariano Martinez Peck <marianopeck@gmail.com>:
On Sun, Jan 10, 2010 at 10:06 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
I agree, it would be nice to have software update for the Pharo images. But as long as it does not reliably work, I think it harms more than it helps.
+1. But...they main question is, do you know in which cases it breaks stuff? ONLY with overrides ? How many overrides do we have from external packages in Core ?
In the 'Packages' page on the wiki, there should be comments about each package indicating if it includes overrides or not. Some months ago I managed to fix all overrides of the different packages in Pharo (aka PharoDev). -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
Can't it be left as user setting that can be selected ('decided') after downloading the image? -- Cesar Rabak Em 10/01/2010 13:45, Mariano Martinez Peck < marianopeck@gmail.com > escreveu: It is a simple question. Do we allow that or not. Miguel wrote the pros and cons: Pros - Can fix bugs after release - Can aply improvements to the image after release. Cons - Can mess the image of someone by overwriting some overridden method. - Can accidentally update more than intended in someone's image We have to take a decision. Cheers Mariano
participants (6)
-
Adrian Lienhard -
csrabak＠bol.com.br -
Damien Cassou -
Mariano Martinez Peck -
Michael Roberts -
Miguel Enrique Cobá Martinez