Typically, a ST image is a combination of the base image, and the change set applied to the image. The change set can be code loaded in from an external source, or someone hacking in the system. By default, all changes made to an image are serialized to a changes file. That way, if your image implodes, you can start with the previous image and roll forward your changes.
That said, projects in general are NOT change sets. They're just collections of classes serialized out as ST source code. These source code files capture the state of the source code within the image, but not the state of the image itself.
Done properly, you don't have any aspects of the source code depending on some existing state within the image, but not captured in a class. But, you don't know that for sure. All of the source code relies somewhat on the vast amount of global state within the image. If global variables make you itch, well, let me introduce to you an ST image.
Pharo is a fork of Squeak, and it's distributed as an image.
Now the Pharo folks have done a lot of VM work, but even in the beginning I imagine that having a chain of custody of source code that converted a stock Squeak image into a nascent Pharo image probably never existed.
I bet even with their long github history it would be very difficult to generate later Pharo images from source code checked in to github.
The ST image is a ball of clay that the developers add to and cut away from in an ad hoc manner. I'm sure they strive to repeatability and such, but I imagine it's not really a high priority for them when some sneaks into a core developers image (which can be from their work, or changes merged from someone else).
Having been raised in a world of "make clean install", where the finished product is a deterministic result of all these pieces I can see and touch, the ST image world has always made me a bit uncomfortable.
Obviously the users cope, and it's a "me" thing, but there you are.
That said, projects in general are NOT change sets. They're just collections of classes serialized out as ST source code. These source code files capture the state of the source code within the image, but not the state of the image itself.
Done properly, you don't have any aspects of the source code depending on some existing state within the image, but not captured in a class. But, you don't know that for sure. All of the source code relies somewhat on the vast amount of global state within the image. If global variables make you itch, well, let me introduce to you an ST image.
Pharo is a fork of Squeak, and it's distributed as an image.
Now the Pharo folks have done a lot of VM work, but even in the beginning I imagine that having a chain of custody of source code that converted a stock Squeak image into a nascent Pharo image probably never existed.
I bet even with their long github history it would be very difficult to generate later Pharo images from source code checked in to github.
The ST image is a ball of clay that the developers add to and cut away from in an ad hoc manner. I'm sure they strive to repeatability and such, but I imagine it's not really a high priority for them when some sneaks into a core developers image (which can be from their work, or changes merged from someone else).
Having been raised in a world of "make clean install", where the finished product is a deterministic result of all these pieces I can see and touch, the ST image world has always made me a bit uncomfortable.
Obviously the users cope, and it's a "me" thing, but there you are.