[igouy]

> i have actively explored working with pharo.

Then you must already know more than me, about what's available now.

Too much? https://github.com/feenkcom/gtoolkit

> … given the image based development you tend to start with a current version of pharo and then keep to that version until you are done.

I think of it as image based development: not image based version control.

[em-bee]

what do you mean by image based version control?

i mean the lack of version control inside the image can be considered a problem, as you have to connect to external tools go get it, lest you save a copy of the image as a version (which is what i would call image based version control), which that is not practical at all.

but that is not what i meant. i was talking about the problem that when i develop an application in pharo 11, but then i want to move the development to pharo 12, that amounts to a lot of work, so i don't do it but i'll stick to pharo 11 until my app is done.

[igouy]

> that amounts to a lot of work

Why? Are you making a lot of changes that conflict with the distro?

"Guideline 120 Avoid modifying the existing behavior of base system classes." :-)

1996 Smalltalk with Style page 95

https://rmod-files.lille.inria.fr/FreeBooks/WithStyle/Smallt...

[em-bee]

it's not the code conflicts, but all the modifications i made to the environment. addons i installed, configurations i changed, windows i opened, code snippets i have in a workspace/playground. pharo is to much like a desktop, and switching to a new version of pharo is like reinstalling my computer and setting up my desktop from scratch.

there is no tool that would just take every change i made to the original pharo image and apply it to the new one.

you know like docker where your base image is immutable and changes to that image are saved in a separate image that is layered on top. so that you can replace the base image while keeping your changes.

[igouy]

> there is no tool that would just take every change i made to the original pharo image and apply it to the new one.

What about Smalltalk?

All your interaction with the IDE is implemented in Smalltalk. For each of the changes you want to preserve, figure out which UI class is used and browse the code to figure out how the UI class makes those changes. Then copy what the UI class does into a workspace script, save the script, and file-in to a clean distro image to check that it works.

Here's an example of a little script being filed-in to load a program, do clean-up and save the image:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[em-bee]

i would want to preserve everything. this is not solvable with a simple script. in docker this feature comes built in. everywhere else all i need to do is copy my homedirectory, and every upgraded application works with the data i have. smalltalks design makes this a magnitude more difficult, and in the end not worth the effort until i get an opportunity to work on a paid project.

[igouy]

> not worth the effort

That's your decision to make and I have no reason to quarrel.