Posted by EstebanLM on Apr 20, 2012; 3:36pm
URL: https://forum.world.st/About-the-new-release-process-tp4574410.html

Hi folks,

Now that Pharo 1.4 is out, I want to talk a bit about our new release process. As you know (if you read the Pharo vision document [1]), we are switching our release process into a more predictable one: time based, not feature based.

We are adopting an "Ubuntu like" model, with one mayor release per year, and two bug fix releases at month 4 and month 8.

So, the next releases will have this numbering: 2.0 big release (we hope to have it in january or february), 2.4 in april and 2.8 in august (all 2013, if Mayans were wrong and we are still alive). During this year we'll also release bugfix versions of Pharo 1.4.

Each major version we want to improve the system in a lot of different ways. These are examples of what we want to achieve during 2.0 development:

-Improve our release process. This is not just by being more predictable, but also about improving the current process technically. For instance, we are going to switch our release building to metacello
configurations, starting with a minimal image. That means: you can take a minimal image and modify a metacello pharoconfig to build the image that you want (on your own responsibility).
– We are going to adopt Opal as new compiler (this will allow us to improve a lot in that area, also to fix important bugs now living in the debugger).
– Replace old SystemChangeNotification with a new announcement based system.
– use Fuel as standard serialization tool (remove SmartRefStream).
– remove old File System (use new based on Filesystem).
– remove old HTTP (use Zinc instead).
– remove old categorizer (Use RPackage instead).
– remove old browser (Use nautilus instead).
– remove old basic tools (use Spec to replace them).
– clean up URL/URI mess (replace with some coherent unique API).

In summary, it is:
a) replacing old subsystems for something better.
b) add new features, which is long-awaited by people.

Most of your projects will not notice the changes, but some might do. In that cases, we will not break backward compatibility just because we want, but there are reasons of improvement. Also, we will follow the deprecation policy we have followed so far (whenever is possible).
We want to invent the future, one step at a time.

Thanks,
Esteban

[1] http://www.pharo-project.org/download/pictures/be/j32hajf3kjdbsebqo0a9zc5tk8ekxt/pharovision.pdf