Re: [Pharo-project] Some clearifications
Stef, Would you not simply fix B2? I could easily be missing something; perhaps B2 is an external package that works in Squeak but clobbers Pharo?? Is it something else? FWIW, I envision a stable release and active development, much as happens on Squeak, just consistent with the Pharo frame of mind. New contributions would tend to go into the development release, some that are of near-term interest could be tested and "back-ported" (aka installed in the next stable release). Every so often, I would further envision doing some type of export of all my stable-version Pharo code and loading into the development release to look for problems or to verify that all is well. Making that export/import cycle as simple as possible will be a useful step in helping people test the development images. Understanding the existing tools is one of my next goals. For Dolphin, I wrote a tool called Migrate that helped to sniff out my packages and overrides and get them loaded in a new image. I would like to find that there is something so slick that Migrate is not needed for Pharo. Failing that, I will port it over, once I figure out what it should do. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab@anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029
stephane.ducasse@inria.fr 10/05/08 5:41 PM >>>
Taking all together I think we need to split upstream. As long as there is only one upstream you can't check that _before_ it gets published. And people see a version in the upstream as the next stable thing. So we need a side channel for integration and testing.
This sounds like a good idea. Now I do not know if this could work because if we integrate B1 B2 B3 B4 and there is a problem we cannot really cancel B2 just add B5 to fix it. Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Oct 6, 2008, at 3:46 AM, Bill Schwab wrote:
Stef,
Would you not simply fix B2? I could easily be missing something; perhaps B2 is an external package that works in Squeak but clobbers Pharo?? Is it something else?
No this is the same in all Smalltalk, if B3 was based on B2. then you have to remove all the streamed elements based on B2.
FWIW, I envision a stable release and active development, much as happens on Squeak, just consistent with the Pharo frame of mind. New contributions would tend to go into the development release, some that are of near-term interest could be tested and "back-ported" (aka installed in the next stable release). Every so often, I would further envision doing some type of export of all my stable-version Pharo code and loading into the development release to look for problems or to verify that all is well.
yes. I think that we can consider that we already have that when we do not publish a new image. We can say that the image is the stable version while the stream elements from the last image are the active part.
Making that export/import cycle as simple as possible will be a useful step in helping people test the development images.
No export. We publish packages
Understanding the existing tools is one of my next goals. For Dolphin, I wrote a tool called Migrate that helped to sniff out my packages and overrides and get them loaded in a new image. I would like to find that there is something so slick that Migrate is not needed for Pharo. Failing that, I will port it over, once I figure out what it should do.
Pharo will change. So you will have to port because even if you press a button that load new components they may change something you rely on.
Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029
stephane.ducasse@inria.fr 10/05/08 5:41 PM >>>
Taking all together I think we need to split upstream. As long as there is only one upstream you can't check that _before_ it gets published. And people see a version in the upstream as the next stable thing. So we need a side channel for integration and testing.
This sounds like a good idea. Now I do not know if this could work because if we integrate B1 B2 B3 B4
and there is a problem we cannot really cancel B2 just add B5 to fix it.
Stef
_______________________________________________ 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
participants (2)
-
Bill Schwab -
Stéphane Ducasse