Due to Pharo/Smalltalk being not just a language, but a language/libraries/IDE, I think it's important to distinguish between API instability (which IHMO is better called evolution) vs. bugginess. API evolution is a core part of Pharo's mission. I've personally upgraded projects from Pharo 1.x all the way to Pharo 7 and have been very willing to trade a small amount of effort porting for big increases in productivity.
I've personally upgraded projects from Pharo 1.x all the way to Pharo 7 and have been very willing to trade a small amount of effort porting for big increases in productivity.
Wow, any chance you've written about the upgrade process?
I don't exactly have a playbook. I generally just fix as I go. I try to install the project, fix any errors, run the test, fix the errors, etc. I can say that some version jumps have been almost no work and probably the max time I've spent is an hour to get everything working. It used to be a bit harder, but nowadays Pharo has automatic refactoring for deprecated methods, which helps...
Comments
Due to Pharo/Smalltalk being not just a language, but a language/libraries/IDE, I think it's important to distinguish between API instability (which IHMO is better called evolution) vs. bugginess. API evolution is a core part of Pharo's mission. I've personally upgraded projects from Pharo 1.x all the way to Pharo 7 and have been very willing to trade a small amount of effort porting for big increases in productivity.
Wow, any chance you've written about the upgrade process?
I don't exactly have a playbook. I generally just fix as I go. I try to install the project, fix any errors, run the test, fix the errors, etc. I can say that some version jumps have been almost no work and probably the max time I've spent is an hour to get everything working. It used to be a bit harder, but nowadays Pharo has automatic refactoring for deprecated methods, which helps...