> … can't upgrade the IDE without upgrading the compiler.
When packaged together IDE & compiler can't be upgraded separately (without doing the work to in-effect make separate packages).
> … can't compile my own code in the image with the old version
So we could try to compile own-code' in image' with compiler', and we could try to compile own-code' in image" with compiler", but we want to try to compile own-code' in image" with compiler' ?
Not without doing the work to in-effect make separate packages. (Say we could port compiler' to image" but would that mean trying to compile compiler' with compiler".)
And now we're back to what does "traditional way of doing smalltalk development" mean because supposedly "Team/V could forward and backwards migrate versions of Smalltalk “modules” within a running virtual image."
> the point of a reproducible build is that a version of source code always produces the same binary.
Scope: does "a version of source code" just mean own-code or does it mean sources+changes.
When packaged together IDE & compiler can't be upgraded separately (without doing the work to in-effect make separate packages).
> … can't compile my own code in the image with the old version
So we could try to compile own-code' in image' with compiler', and we could try to compile own-code' in image" with compiler", but we want to try to compile own-code' in image" with compiler' ?
Not without doing the work to in-effect make separate packages. (Say we could port compiler' to image" but would that mean trying to compile compiler' with compiler".)
And now we're back to what does "traditional way of doing smalltalk development" mean because supposedly "Team/V could forward and backwards migrate versions of Smalltalk “modules” within a running virtual image."
> the point of a reproducible build is that a version of source code always produces the same binary.
Scope: does "a version of source code" just mean own-code or does it mean sources+changes.